Onkar's Oracle Cloud and Fusion Middleware Blog: July 2013

If you haven't already, read this post. It gives a basic overview as to why we should split all ADF components from SOA/BPM, and the options available around this process as well as their pros and cons.

Oracle Documentation also provides a similar guide on this process (link). The difference is that this post is more specific and in-depth, trying to provide a more thorough guide from start to finish.

Versions of Oracle technology this post utilizes:
Weblogic: 10.3
JDeveloper: 11.1.1.6.0
BPM 11g

So we have a server (soa_server) and deployed to it are SOA + BPM processes + BPM ADF UI's (Human task pages) + an ADF application that manages the BPM solution. We shall be migrating all ADF components + BPM Task pages to a newly created managed server under the same server node, thus restoring the connection between the BPM process and its Task page over different server ports.

I will be referring to the SOA server that currently has all deployments as soa_server, and the newly created ADF/UI server as ui_server.

Pre-requisites
1. Un-deploy all UI (ADF + BPM task pages) from soa_server.

BPM Task page application - wf_client_config.xml
We need to include the above XML file into your BPM Task page application code so that when deployed to the ui_server, it will register to its corresponding BPM Process that resides on the soa_server. The property that refers to weblogic.jndi.WLInitialContextFactory will be created shortly.

Note: Each BPM Task page will require the insertion of this wf_client_config.xml file

1. We need to create a new XML file (if it does not already exist) called wf_client_config.xml under the directory: bpm_ui_code/public_html/WEB-INF/classes

2. Use the following template as the body of the code:

wf_client_config.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowServicesClientConfiguration  xmlns="http://xmlns.oracle.com/bpel/services/client" clientType="REMOTE">
   <server default="true" name="default">
      <localClient>
         <participateInClientTransaction>false</participateInClientTransaction>
      </localClient>
      <remoteClient>
         <serverURL>t3://server_hostname_address:8001</serverURL>
         <initialContextFactory>weblogic.jndi.WLInitialContextFactory</initialContextFactory>
         <participateInClientTransaction>false</participateInClientTransaction>
      </remoteClient>
      <soapClient>
         <rootEndPointURL>http://server_hostname_address:8001</rootEndPointURL>
         <identityPropagation mode="dynamic" type="saml">
            <policy-references>
               <policy-reference enabled="true" category="security" 
                uri="oracle/wss10_saml_token_client_policy"/>
            </policy-references>
         </identityPropagation>
      </soapClient>
   </server>
</workflowServicesClientConfiguration>

3. Do not forget to update the server_hostname_address for serverURL and rootEndPointURL. An example could be:

<serverURL>t3://tom.company-name.co.uk:8001</serverURL>
<rootEndPointURL>http://tom.company-name.co.uk:8001</rootEndPointURL>

4. Once complete, save the file. The rest of the configurations will take place inside the Server Console and EM.

Create new UI server
1. Log into your Server Console

2. Click servers and click New

3. Enter the following details:

Server Name: ui_server
Server Port: 8020 (You can choose any new port number, as long as it is not already used)
Should this server belong to a cluster? No, this is a stand-alone server

4. Click Finish

5. Click on the newly created server: ui_server

6. Click on the drop down for Machine and select your domain address from the list

7. In Listen Address, type your domain address

8. Click Save, then Activate Changes

9. Click on Servers, click Lock & Edit, click the Control tab, select ui_server and then click Start, and click Yes on the next screen.

Apply the Java Runtime Files (JRF) Template
When the JRF Template is applied to a Managed Server, the ADR libraries are added to the server in order to run ADF based application successfully:

1. Log into your Server EM

2. Expand the Weblogic Domain

3. Expand your_domain and click on ui_server

4. On the main panel, there is a button at the top 'Apply JRF Template'. Click on the button

5. Return to the Server Console and restart ui_server.

Configure Data Sources for ui_server
You need to point any Data Sources (Databases, MDS repositories etc) that are used in the application to the new ui_server:

1. Log into your Server Console

2. Click on Data Sources, click on your_data_source, click the Targets tab and tick the ui_server target. (Save and Activate changes)

3. Repeat the above step for all Data Sources that are used in your application.

Configure required Libraries for ui_server
Similar to configuring the Data Sources, we want to do the same for any libraries that are used by the ADF or BPM Task pages:

1. Log into your Server Console

2. Click on Deployments

3. You need to find out what specific libraries are used by your application. You can find some of the libraries by analysing the source code of weblogic-application.xml, which is found under every project (Application Resources -> Descriptors -> META-INF). The application I worked on used the following libraries:

- adf.oracle.domain
- adf.oracle.domain.webapp
- oracle.soa.workflow.wc
- oracle.soa.workflow
- oracle.soa.worklist.webapp
- oracle.soa.bpel
- oracle.bpm.runtime
- oracle.jsp.next
- jsf
- jstl

3. For each of the identified libraries, click on each one from the deployments list, then click the Targets tab and tick the ui_server target. (Activate changes after each one).

Create a new Foreign JNDI Provider
This new Foreign JNDI Provider is what the code in wf_client_config.xml will refer to, to allow the BPM Task page to communicate with its BPM Process on the soa_server

1. Log into your Server Console

2. Click on Services, click Foreign JNDI Providers and click New:

a. Set Name as: ForeignJNDIProvider-SOA
b. Click Next
c. Select the following as Targets - soa_server; ui_server
d. Click Finish
e. Click on the newly created Foreign JNDI Provider - ForeignJNDIProvider-SOA
f. Enter the following details:
i) Initial Context Factory: weblogic.jndi.WLInitialContextFactory
ii) Provider URL: t3://soa_hostname:soa_portnumber/soa-infra
iii) User: Weblogic username (weblogic)
iv) Password: Weblogic password (welcome1)
vi) Save and Activate changes.

3. Click the Links tab for the above ForeignJNDIProvider-SOA

4. For each of the 14 JNDI Links below, click New and create a Link with the specified information:

Name: ejb/bpel/services/workflow/TaskMetadataServiceBean
Local JNDI Name: ejb/bpel/services/workflow/TaskMetadataServiceBean_local
Remote JNDI Name: ejb/bpel/services/workflow/TaskMetadataServiceBean

Name: ejb/bpel/services/workflow/TaskServiceBean
Local JNDI Name: ejb/bpel/services/workflow/TaskServiceBean_local
Remote JNDI Name: ejb/bpel/services/workflow/TaskServiceBean

Name: ejb/bpel/services/workflow/TaskServiceGlobal/TransactionBean
Local JNDI Name: ejb/bpel/services/workflow/TaskServiceGlobal/TransactionBean_local
Remote JNDI Name: ejb/bpel/services/workflow/TaskServiceGlobal/TransactionBean

Name: ejb/bpm/services/BPMUserAuthenticationServiceBean
Local JNDI Name: ejb/bpm/services/BPMUserAuthenticationServiceBean_local
Remote JNDI Name: ejb/bpm/services/BPMUserAuthenticationServiceBean

Name: ejb/bpm/services/InstanceManagementServiceBean
Local JNDI Name: ejb/bpm/services/InstanceManagementServiceBean_local
Remote JNDI Name: ejb/bpm/services/InstanceManagementServiceBean

Name: ejb/bpm/services/InstanceQueryServiceBean
Local JNDI Name: ejb/bpm/services/InstanceQueryServiceBean_local
Remote JNDI Name: ejb/bpm/services/InstanceQueryServiceBean

Name: ejb/bpm/services/ProcessDashboardServiceBean
Local JNDI Name: ejb/bpm/services/ProcessDashboardServiceBean_local
Remote JNDI Name: ejb/bpm/services/ProcessDashboardServiceBean

Name: ejb/bpm/services/ProcessMetadataServiceBean
Local JNDI Name: ejb/bpm/services/ProcessMetadataServiceBean_local
Remote JNDI Name: ejb/bpm/services/ProcessMetadataServiceBean

Name: ejb/bpm/services/ProcessModelServiceBean
Local JNDI Name: ejb/bpm/services/ProcessModelServiceBean_local
Remote JNDI Name: ejb/bpm/services/ProcessModelServiceBean

Name: RuntimeConfigService
Local JNDI Name: RuntimeConfigService_local
Remote JNDI Name: RuntimeConfigService

Name: TaskEvidenceServiceBean
Local JNDI Name: TaskEvidenceServiceBean_local
Remote JNDI Name: TaskEvidenceServiceBean

Name: TaskQueryService
Local JNDI Name: TaskQueryService_local
Remote JNDI Name: TaskQueryService

Name: TaskReportServiceBean
Local JNDI Name: TaskReportServiceBean_local
Remote JNDI Name: TaskReportServiceBean

Name: UserMetadataService
Local JNDI Name: UserMetadataService_local
Remote JNDI Name: UserMetadataService

5. Save and Activate Changes

6. Click on the Targets tab for the newly created ForeignJNDIProvider-SOA

7. Ensure that soa_server and ui_server are ticked

8. Save and Activate changes

9. Restart both soa_server and ui_server (Shutdown then Start up).

Deployment of BPM Task pages + ADF
1a. If you are deploying your ADF/BPM Taskpage using JDeveloper, ensure you select the ui_server when selecting what managed server to deploy to

1b. If you are deploying using scripts (WLST), ensure you make the modifications required such as the name of the managed server or the port number to deploy to

2. Following the above deployment, your BPM Task should now be successfully registered with their corresponding BPM Processes that reside on the soa_server. Clicking on a task link should open the task page whose processing will take place on the ui_server.

Note
This process can also be followed during the architecture set up before any development takes place so that right from the beginning, all ADF deployments are on a separate server to any other non-ADF components.

When deploying to different environments further down the line (From a Development to Test environment), be sure to update any end points you have defined that initially point to a specific server. E.g. The server end points located in wf_client_config.xml (ServerURL and RootEndPointURL properties).

Any questions, feel free to ask.

This post explores at a high level why we should split all ADF related components (ADF/BPM UI task pages) from relating SOA/BPM components onto separate servers. The post concludes with a link to another post which shows the steps required to implement one of the offered solutions.

I worked on a BPM application that was made up of SOA, BPM processes, relating BPM UI's and an ADF application that managed the BPM solution. All of these components were initially deployed onto 1 managed SOA server.

When the application was given to the client and it reached the UAT phase, the stress load on it increased as more users were using the system, this led to a massive drop in performance and left the application sometimes unusable. Due to the lack of resources whilst developing the application, we did not know that there would essentially be a performance issue as the number of users increased. After further investigation, we found that the initial architecture of having deployed all components on 1 server was a bad approach, and concluded that we needed the SOA/BPM and UI components onto separate managed servers so that each would have its own JVM and memory allocations, rather than 1 big memory allocation responsible for processing the whole application concurrently.

Architecture solution options
The solution offers essentially 2 architecture options:

Option A) A single node solution: This will lead to multiple managed servers running under 1 node (SOA/BPM server; ADF server). Each server will have its own port and the solution will lead to the BPM UI's successfully communicating with their respective BPM processes on the SOA server.

Pro's: Each server will have its own JVM and RAM allocation.

Con's: Each server will share the overall CPU power available on the system and cannot be allocated to 1 server more than the other.

Option B) A multiple node solution (Clustered): This will involve multiple servers and each server will have multiple nodes. Each server will run only specific components (SOA/BPM; ADF). Load balancing can be implemented to support multiple nodes under each server.

Pro's: Each server will have its own JVM, RAM and CPU power allocation. It is a future proof solution as it is easier to scale up, e.g. If the number of users increase, we can install more memory for a certain component and increase the number of nodes that will process the required work. This option provides a very flexible and recommended architecture.

Con's: More expensive and a little more complex to implement than option A. This option may require more licenses from Oracle due to the extra CPU cores utilized.

Conclusion
Obviously, utilizing any of the above solutions will result in much better performance compared to having everything deployed under 1 server. The solutions lead to ADF being less dependence on the SOA components, thus minimizing the workload for all separate components. However, you must weigh up the pro's and con's of each and decide given your requirements/constraints what solution to implement. I believe that option B will be the solution that would be recommended by Oracle due to it offering the best working practices from a future proof perspective.

Steps to implement solution option A
Due to time and budget constraints, we agreed to go ahead and offer + implement a solution for Option A. The following post link highlights what is required to separate the ADF UI components from the SOA server to fulfill Option A. We will create a new UI server, configure server settings, make a change to the application code, and then re-deploy the UI components to the new UI managed server (different port number).

How to separate BPM 11g ADF Task page components from SOA/BPM to a new ADF managed server

How to separate BPM 11g ADF Task page components from SOA/BPM to a new ADF managed server

Why should we separate ADF from SOA/BPM components onto multiple servers - Single node or Clustered?