If you have moved your IBM BPM Process Center (DEV) environment (by performing a new installation of IBM BPM on new servers) to a new hardware with the existing databases or if you have restored a copy of the database in a different place and want to use it with a different Process Center (DEV) environment then you might run into a problem on your first startup of IBM BPM server. It's related to an un-named snapshot automated deletion configuration. If it was configured in your old PC/DEV it would store a hostname of a previous server in one of the related tables.
Here is a snippet from FFDC log generated during a startup of an IBM BPM server -
(pay attention to parts where it says "
OUR_OLD_HOST_WILL_BE_HERE (YOUR_OLD_IP), Port: YOUR_PORT) - these would be indications of the issue because it would be trying to use your old host for something -
[2/2/19 4:07:29:235 EST] FFDC Exception:com.ibm.websphere.scheduler.NotificationException SourceId:startService ProbeId:2 Reporter:java.lang.String@cde07519 com.ibm.websphere.scheduler.NotificationException: SCHD0137E: Unable to create EJB instance for NotificationSink: javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 No; nested exception is: org.omg.CORBA.TRANSACTION_ROLLEDBACK: vmcid: 0x0 minor code: 0 completed: No SCHD0140I: EJB information: Host: YOUR_OLD_HOST_WILL_BE_HERE (YOUR_OLD_IP), Port: YOUR_PORT, J2EE component: IBM_BPM_Teamworks_BRK_PC.APPCluster#SharingNotificationBean.jar#Sink
Caused by: javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 No; nested exception is: org.omg.CORBA.TRANSACTION_ROLLEDBACK: vmcid: 0x0 minor code: 0 completed: No at com.ibm.CORBA.iiop.UtilDelegateImpl.mapSystemException(UtilDelegateImpl.java:291) at javax.rmi.CORBA.Util.mapSystemException(Util.java:78) at com.ibm.websphere.scheduler._NotificationSinkHome_Stub.create(_NotificationSinkHome_Stub.java:228) at com.ibm.ws.scheduler.NotificationSinkHolder.createBeanInstance(NotificationSinkHolder.java:273) ... 34 more Caused by: org.omg.CORBA.TRANSACTION_ROLLEDBACK: vmcid: 0x0 minor code: 0 completed: No at com.ibm.ws.Transaction.JTS.TxClientInterceptor.receive_common(TxClientInterceptor.java:355) at com.ibm.ws.Transaction.JTS.TxClientInterceptor.receive_exception(TxClientInterceptor.java:149) at com.ibm.rmi.pi.InterceptorManager.invokeInterceptor(InterceptorManager.java:580) at com.ibm.rmi.pi.InterceptorManager.iterateClientInterceptors(InterceptorManager.java:419) at com.ibm.rmi.pi.InterceptorManager.iterateReceiveException(InterceptorManager.java:673) at com.ibm.rmi.corba.ClientDelegate.intercept(ClientDelegate.java:897) at com.ibm.rmi.corba.ClientDelegate.invoke(ClientDelegate.java:439) at com.ibm.CORBA.iiop.ClientDelegate.invoke(ClientDelegate.java:1377) at com.ibm.rmi.corba.ClientDelegate.invoke(ClientDelegate.java:695) at com.ibm.CORBA.iiop.ClientDelegate.invoke(ClientDelegate.java:1407) at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:484) at com.ibm.websphere.scheduler._NotificationSinkHome_Stub.create(_NotificationSinkHome_Stub.java:215) ... 35 more
The cause of the error is related to the configuration of automated un-named snapshot cleanup in IBM BPM DEV / Process Center environments. You can find more details about this topic here.
Once you configure it in Process Center server it adds a record to the table in the database and one of the columns in that table actually contain an FQDN (fully qualified domain name) of a BPM servers where this was configured on. It uses WebSphere Schedulers to do this job.
Luckily there is a simple resolution to this problem. Follow these steps -
1) Stop Deployment Environment (e.g. stop all WebSphere Application servers/clusters). Leave Deployment Manager and nodeagents running.
2) Login to WAS admin console -> Resources -> Schedulers and find a scheduler with a name like "ProcessCenterSharingScheduler" - see screenshot below:
3) Select "ProcessCenterSharingScheduler" and click on Drop tables (it drops 4 tables used for this scheduling called - BPM_PCS_LMGR , BPM_PCS_LMPR, BPM_PCS_TASK , BPM_PCS_TREG, so, if have concerns about the drop you may take a backup of above 4 tables in BPM database schema first) -
You should see a message that says "Tables were dropped successfully".
4) Select "ProcessCenterSharingScheduler" again and this time click on "Create tables" -
You should see a message that says "Tables were created successfully".
You can check BPM database schema to verify that the tables were successfully recreated.
It's possible that if your server (BPM) is still trying to start during this operations or is in partial start it would block those tables. So, make sure you stop it as instructed in step 1 before you execute resolution steps.
If you still see an error (database related) that the tables cannot be dropped then most likely it's due to existing blocks on the tables in question that were not released. So, you may safely kill the database sessions on the database server associated with those 4 tables and then you can retry the Drop and Create from WAS admin console.