Common things for the BPEL process that need to be considered when planning to migrate from WPS 6.2 to BPM 8.5.x
Xin Yang 120000GYBH Visits (8567)
The Business Process Execution Language (BPEL) process has been part of WebSphere Process Server (WPS) for several years. When you plan to migrate from WPS 6.2 to Business Process Manager (BPM) 8.5.x, there are several common things you need to consider to prevent problems and help the migration go smoothly.
The BPEL process is driven by the BPE engine and TASK engine. The basic behavior of these engines has no change from WPS 6.2 to BPM 8.5.x, therefore, in normal cases, migrating from WPS 6.2 to BPM 8.5.x will not impact the BPEL process. However some small changes in BPM 8.5.x may cause some problems after migration, so while planning the migration, the below items need to be considered.
The Client Application which uses BPE and TASK EJB APIs
In WPS, it is very common for using BPE and TASK EJB APIs developing client application to access BPEL process/Tasks remotely. In WPS 6.2, there is a WPS client that can be installed on the remote WebSphere Application Server which can provide the required jar files that support using the BPE and TASK APIs. In BPM 8.5.x, the client (like WPS client) is deprecated. If you want to use the remote client application which you developed while using WPS, it needs to be installed on another BPM instance instead of the WebSphere Application Server/WPS client (deprecated in BPM). It then can support running the client application remotely.
In WPS 6.2, there were two jar files, bpe137650.jar and task137650.jar, that needed to be packaged with the client application in order to access the BPE and TASK EJB APIs. For BPM, these two jar files are no longer needed and as part of preparing for the migration, these two jar files need to be removed from the client application package. The jar files contain the same name interface and method as the new BPM 8.5.x BPE and TASK container, which may lead to the wrong version of interface and method to be loaded into the classloader at run time and cause errors.
The Shared Work Items
Process Instance Versioning
One common scenario is that you have some process template that needs to modified. After migration the hope is that the old process instances can migrate to the new process template and run with the new code of the new version.
This function is called instance versioning, which was introduced in WPS 7 and BPM 8.5.x. If your migration path is from an older version of WPS, like WPS 6.2, the instance versioning function is not available. This means that you can not migrate your old process instances to the new process template. While planning the migration from WPS 6.2 to BPM 8.5.x, consider all the old version process instances on WPS 6.2 and run the new version process instances on BPM 8.5.x. This needs to be planned as it will impact the business and the time frame of the migration. Below is the suggested way.
1. Deploy a new/corrected BPEL version on the WPS 6.2 system.
3. Keep the WPS 6.2 system running until all current running instances of the problem BPEL template are finished (any active instances would then be of the new corrected BPEL version).
Keep in mind that the product design assumptions and testing are based on any new BPEL version being deployed in a new application. Use of the replacement of a single module has the potential to break compatibility between the Generate process classes and the template definitions stored in the database, or to cause issues between generated classes.
Deploying BPEL process and human task applications states that "Each new version of a model that is to be deployed must be packaged in a new enterprise appl
Therefore, do not try to modify the process template and then replace the single module.
Staff Query Refresh
Staff query refresh is a very useful function to make the staff query result up to date. The function has no change, but if you are facing problems when using staff query refresh after migrating to BPM 8.5.x, below are some items that should be checked.
The first thing to check is shared work items. There are some cases that show in WPS 6.2 without shared work items function, the people query result is correct and the corresponding tasks can be assigned without problem. However in BPM 8.5.x, even when there is no error, the task does not get assigned to the correct person and instead assigned to administrator. In such cases, you should consider disabling the shared work item help resolve this type of issue.
There are also 2 known issues with staff query refresh on BPM 8.5.x which should be considered
One is APAR JR53782 which is for the problem when running the refr
Another issue is noted in the APAR JR50387. This problem is fixed in BPM 8.5.6. If your migration path is to BPM 8.5.5, the fix of this APAR is included in the ifix for APAR JR51941. Ifix of APAR JR51941 is for Process Federation Server and APAR JR50387. There is no need to follow the "Post Installation Manager Install Instructions" after installation of the ifix.