Configuring endpoints for dynamic URLs

Before you start, you should make sure to read the documentation on Configuring Business Automation Workflow endpoints to match your topology to understand how overall endpoint behavior works. In addition, make sure you have a topology diagram, know how you want different use cases to work, and what URLs should be used in each case before you look at configuring endpoints in BAW.

Overall, when you have multiple use cases you should be looking at the different endpoint strategies along with the optional scenario keys potentially. In particular, the different endpoint strategies can generally be split up into two different categories: dynamic and static strategies. Static strategies would return the exact same URLs every time the scenario is triggered, while a dynamic one would return different URLs based on certain criteria (generally based on the headers in a HTTP session). Thus, for the Strategies for identifying endpoint information, the following strategies would generally be static:

Meanwhile these strategies would be considered dynamic and generally use HTTP headers to determine the URLs to generate:

The RelativeUrlStrategy would also be dynamic but it is specifically designed to only be used in the case of the relative scenario and should not be used outside of it.

For example, lets consider an example where you have two different sets of users connecting to Process Portal using both a webserver URL and direct node URLs like this:
https://nodeurl:9443/ProcessPortal
https://webserverurl/ProcessPortal

Normally for simple setups that requires a static URL, you should follow Customizing Business Automation Workflow to work with a web server, which would direct all URLs to go to the same URL.

For example, if you try to use those steps we would expect the following endpoint configuration:

<virtualHosts xmi:id="BPMVirtualHostInfo_1602436164312" hostname="webserverURL" transportProtocol="https" name="webserver"/>
    <bpmurls xmi:id="BPMURLS_1559237594777">
      <bpmurl xmi:id="BPMURL_1559237594777" strategies="WCCMConfigStrategy, HttpProtocolHostStrategy" scenario="EXTERNAL_CLIENT" virtualHost="BPMVirtualHostInfo_1602436164312/>
...

This type of setup would result in the https://webserverURL/Context Root/ being returned every time the EXTERNAL_CLIENT scenario is encountered. This is due to the WCCMConfigStrategy being a static strategy that will always return the same hostname URL every time it is selected. Hence, even if you log into Process Portal with the nodeurl URL, many of the links returned would be for the webserverurl instead.

However, if you would want one set of users (such as the Admin users) to connect with the direct node URLs while the other set of users (such as the Business users) use the web server URL, then you would not want a static URL. For this type of a use case, where you need to have two different URLs such as webserverurl and nodeurl work at the same time, the endpoints should be set to use a dynamic strategy first. To do this, we could simply take the prior endpoint setup and reverse the order of the strategies like this:

<virtualHosts xmi:id="BPMVirtualHostInfo_1602436164312" hostname="webserverURL" transportProtocol="https" name="webserver"/>
    <bpmurls xmi:id="BPMURLS_1559237594777">
      <bpmurl xmi:id="BPMURL_1559237594777" strategies="HttpProtocolHostStrategy, WCCMConfigStrategy" scenario="EXTERNAL_CLIENT" virtualHost="BPMVirtualHostInfo_1602436164312/>
...

This would lead to a different behavior as now the first strategy being checked is the HttpProtocolHostStrategy. That strategy is a dynamic one that uses the HOST header of the HTTP call (which is a mandatory header for all HTTP communication) in order to determine what URL should be used. Hence if you logged into Process Portal with the webserverurl, all of the external links in that page would use the webserverurl; while if you logged in with the nodeurl, it would instead return external links with the nodeurl. The only case the HttpProtocolHostStrategy would not be used is if there was no HTTP call involved, in which case the HttpProtocolHostStrategy would fail and then BAW would check the next strategy of WCCMConfigStrategy, which would return the webserverurl.

For more complex topologies, you can have your web server insert the URL to use in a custom header such as with the BpmHeaderAbsoluteStrategy. That would allow your web server to perform the logic of determining which URL should be used for the user trying to access BAW. This is especially useful as a way to route users to different URLs even if they end up using the same one to access BAW.

A good example of where this would be useful would be a case where there would be no prexisting HTTP session to use. For example, if you are using task notification emails in Process Portal, the links sent out in the notification emails would not have a HTTP session associated with them, hence would end up using the WCCMConfigStrategy in the above use case which would always return the same static URL. If you needed two different URLs to be provided to the two different types of business users there would not be a way for BAW on it's own to tell which URL should be used. In those use cases we would suggest routing to a web server via a virtualhost and WCCMConfigStrategy that both types of users has access to. From there, you can have the web server do the logic of determine which type of business user is connecting to modify the headers in order to route to the appropriate URL.

For example, lets say your web server knows which category each user is and which URL they should be routed to and it is set to add on the com.ibm.bpm.routing.HostAndURIPrefix header to note the URL. In that case, you would want to reorder the strategies so that the BpmHeaderAbsoluteStrategy is used before the HttpProtocolHostStrategy like this:

<virtualHosts xmi:id="BPMVirtualHostInfo_1602436164312" hostname="webserverURL" transportProtocol="https" name="webserver"/>
    <bpmurls xmi:id="BPMURLS_1559237594777">
      <bpmurl xmi:id="BPMURL_1559237594777" strategies="BpmHeaderAbsoluteStrategy, HttpProtocolHostStrategy, WCCMConfigStrategy" scenario="EXTERNAL_CLIENT" virtualHost="BPMVirtualHostInfo_1602436164312/>
...

In this case, we are assuming the web server would be adding in a com.ibm.bpm.routing.HostAndURIPrefix header to redirect you to the correct URL. In that case, for the same scenario, if you used the web server URL, it would automatically provide the header which URL the user should be using, which would redirect any users that should be using the nodeurl. That said, if that header is not there (say you are already using the node URL), then the BpmHeaderAbsoluteStrategy would fail and it would fall back to using HttpProtocolHostStrategy. Lastly, if there is not HTTP session (such as the task notification emails), the server would use the WCCMConfigStrategy URL which would route to the web server by default.

Lastly, occasionally there are specific scenarios where you want particular URLs to only be used. A good example of this would be with desktop Process Designer connecting to an online Workflow Server. A common scenario would be if you have a SSO setup for a production Workflow Server for any inbound calls from outside of your intranet. However, Process Designer connections to that Workflow Server may not work with SSO so you would want to use a different internal URL that would bypass the SSO check for connections from Workflow Server to Process Designer. In that case, you would want to hard code the URL to be used only for that particular scenario, while all other external traffic uses the external URL by default. To do this, you would use the optional scenario keys so that only that one use case would use the internal URL. To do this, you first would want to get a list of the optional optional scenario keys used by Process Designer to connect to Workflow Servers, which are all documented in the Connections from desktop Process Designer to IBM Workflow Server page:

 

• AE_TO_PS
• PROCESS_CENTER
• AE_IMAGES_PREFIX
• AE_PORTAL_PREFIX
• AE_WEBAPI_PREFIX
• AE_SERVLET_PREFIX
• AE_BPM_REST_SERVICE_CR_PREFIX
• AE_SOCIALBUS_WEBAPP_PREFIX
• AE_REST_GATEWAY_CR_PREFIX

<virtualHosts xmi:id="BPMVirtualHostInfo_1602436164312" hostname="webserverURL" transportProtocol="https" name="webserver"/>
<virtualHosts xmi:id="BPMVirtualHostInfo_1602436174326" hostname="internalURL" transportProtocol="https" name="process_designer_url"/>
    <bpmurls xmi:id="BPMURLS_1559237594777">
      <bpmurl xmi:id="BPMURL_1559237594777" strategies="BpmHeaderAbsoluteStrategy, HttpProtocolHostStrategy, WCCMConfigStrategy" scenario="EXTERNAL_CLIENT" virtualHost="BPMVirtualHostInfo_1602436164312/>
      <bpmurl xmi:id="BPMURL_1531428262140" strategies= "WCCMConfigStrategy" scenario="AE_TO_PS" virtualHost="BPMVirtualHostInfo_1602436174326"/>
      <bpmurl xmi:id="BPMURL_1531428262199" strategies= "WCCMConfigStrategy"scenario="PROCESS_CENTER" virtualHost="BPMVirtualHostInfo_1602436174326"/>
      <bpmurl xmi:id="BPMURL_1531428262225" strategies= "WCCMConfigStrategy"scenario="AE_IMAGES_PREFIX" virtualHost="BPMVirtualHostInfo_1602436174326"/>
      <bpmurl xmi:id="BPMURL_1531428262284" strategies= "WCCMConfigStrategy"scenario="AE_PORTAL_PREFIX" virtualHost="BPMVirtualHostInfo_1602436174326"/>
      <bpmurl xmi:id="BPMURL_1531428262579" strategies= "WCCMConfigStrategy"scenario="AE_WEBAPI_PREFIX" virtualHost="BPMVirtualHostInfo_1602436174326"/>
      <bpmurl xmi:id="BPMURL_1531428262616" strategies= "WCCMConfigStrategy"scenario="AE_SERVLET_PREFIX" virtualHost="BPMVirtualHostInfo_1602436174326"/>
      <bpmurl xmi:id="BPMURL_1531428262813" strategies= "WCCMConfigStrategy"scenario="AE_BPM_REST_SERVICE_CR_PREFIX" virtualHost="BPMVirtualHostInfo_1602436174326"/>
      <bpmurl xmi:id="BPMURL_1531428262870" strategies= "WCCMConfigStrategy"scenario="AE_SOCIALBUS_WEBAPP_PREFIX" virtualHost="BPMVirtualHostInfo_1602436174326"/>
      <bpmurl xmi:id="BPMURL_1531428262907" strategies= "WCCMConfigStrategy"scenario="AE_REST_GATEWAY_CR_PREFIX" virtualHost="BPMVirtualHostInfo_1602436174326"/>
...

With that setup, only the Process Designer URLs would be going to that internal URL while all other URLs would be using the EXTERNAL_CLIENT scenario which would be using the same strategies as before.

As you can see, endpoints are a very powerful tool when configuring BAW in an environment with a complex topology and can let you configure BAW to work in a multitude of different use cases.

You can check what an endpoint is currently set to in your BAW environment using the following URI:

The specificScenario is the optional scenario you are interested in and the defaultScenario is the default scenario you are interested in. In addition, if you want to track how the endpoints are being used to determine the URL to be returned on the system, you can enable a trace of "com.ibm.bpm.endpoint.*=all" to collect that information.