This article applies to Oracle BPEL Process Manager - Version: 10.1.3.3 to 10.1.3.4 and describes how to migrate BPEL processes including in-flight instances running on one environment to a completely new environment.
Lets take below use case to understand how migration can take place.
Use-case:
BPEL is running on a single instance mid-tier against a single instance Oracle database 10.2.0.3.
This will be moved to a new mid-tier server running against a new RAC Oracle database 10.2.0.3.
Please follow below steps to achieve the goal.
1. Install SOA schemas on RAC Database by running IRCA scripts.
2. Install mid-tier and patch it to 10.1.3.3 or above.
3. Shutdown the mid-tier and database.
4. Replace the new ORABPEL Schema (on RAC) with the original ORABPEL schema where BPEL Process instances are Dehydrated.
This can be done by database export and import.
5. Start the mid-tier and database.
You should now be able to see all BPEL process in new BPEL console and the temporary files for BPEL processes are regenerated.
6. All BPEL processes (including one with Human Tasks running with OracleAS Single Sign-On) should have been successfully migrated.
All opened instances should be able to finish and new instances could be started from the same BPEL processes.
- before step (5) you have to edit the BPEL table PROCESS_DESCRIPTOR, field DESCRIPTOR and change the property name wsdlLocation to the new server:port values.
- The whole procedure will work just fine for new instances of deployed BPEL Processes. However for old instances we had to open in the old BPEL Server theHTTP Port where WSDL were publish because migrated opened instances were always trying to reach that server:port when the main BPEL Process call other (inner)BPEL Processes defined on it.
eg: Main BPEL Process "A" is invoked in new server:port WSDL Location (this instance was migrated from the previous server; new instances work just fine).
When the process "A" is dehydrated and calls a second BPEL Process, say process "B", it does the call over the old server:port WSDL location.
We could not figure out how to resolve this issue so we started a listener process (iptables) on the old server that redirect all the trafic to the new server:port. So invocation of old WSDL locations are redirected to the new server:port values. This configuration will have to exist until old instances migrated from the previous server are finished. New instances of BPEL processes do not have this problem.
In step (6) "All opened instances should be able to finish and new instances could be started from the same BPEL processes." is not completely true. Is there any other way to get this working fine without using redirection from old server to new one.
I have a similar scenario wherein we are migrating from one linux box to another but not changing the SOA version. We have cloned the BPEL server instance and created new servers out of that and also able to see all the bpel processes on this new server.
ReplyDeleteNow I guess as per your information above we need to modify the partner links url in our hydration store so that it points to correct urls.
I cannot understand what will happen to our already long running bpel instances, does changing the descriptor column will have any effect on those running instances ?
Also can you please share more details on IPtables configuration. Actully once we do the cutover our old servers will be switched off so how will IPtable help us in that scenario?