The Source of BPM’s getTaskDisplayURL()

When integrating a BPM task into a BPM Workflow UI the SOA Engine will call getTaskDisplayURL() and append “workflow” and then the name of the deployed UI application.

How does SOA generate this URL? And furthermore, how does it know whether or not to use HTTPS? The details are determined by the SOA Server’s HTTP Frontend value in the Weblogic Console, and they are set at deployment time.

If you don’t set any value in the cluster settings, Weblogic will default to whatever name it can resolve for its listening IP address. Usually this will be the hostname of the server, but it means that if you configure a “local” hostname in your operating system’s hosts file it can cause problems if your client does not have the same mapping of IP and Hostname in their local hosts file.

To ensure the value is correct, change the settings in your cluster as follows.

Admin Console -> Environment -> Clusters -> Configuration [HTTP Tab] -> Frontend Host

Enter the hostname and port you want the task UI to be shown on.

If your server does not use HTTPS then leave the HTTPS field blank.

After saving the changes you will need to bounce the whole cluster.

Finally - only once the cluster restart is completed - you need to re-deploy the UI Component to the SOA Domain where it will re-load the value for the TaskDisplayUrl.

SOA Returning the wrong value for LOCAL_CLIENTLOCAL Constant

While building a Oracle Fusion Middleware stack on a single RedHat 6 VM an entry was added to the /etc/hosts file to spoof another URL bound to the SOA’s local listen address.

The (sanitzed) entry was:

128.128.128.128 old-env.example.com

Further along in the setup of this environment the hosts entry was removed. However, issues occurred in SOA/BPM whengetFactory().getBPMServiceClient() was called to set the LOCAL_CLIENTLOCAL Constant. It was returning old-env.example.com which was no longer a valid URL.

After hunting through MBean Directory, Config Plans and MDS Schema we fortunately we recalled that this value had been set in /etc/hosts. Performing a restart of the whole domain (Admin Server, SOA, OSB, NodeManager) did not help.

Clearly some caching of the invalid hostname was being done, most likely at an OS level due to the JVM restarts achieving nothing.

As this was a development environment the VM could be easily rebooted, and this resolved the cached Domain Name.