You ever wondered how to reset a BPM system to a state earlier in time? You ever wanted to know if it is possible to clean up a BPM system to revert back to the state which it had after the first installation?
Today I will give you the answers to those questions.
First of all in order to tell what you need to do to clean up a system or revert back to an earlier state you need to understand what modifications are done when you run the system over time.
Guess what, the first thing of cause is
Data in the database
Whenever a process instance is touched (be it started, run, terminated or whatever you do with your instances), data is being inserted or updated in the database. This is the same independent of whether you are running BPMN applications or BPEL applications. Both a heavily using the database to store a consistent state of what you are doing.
When transactions are run against the database we also store
Data in the transaction logs
The transaction service writes information to a transaction log for every global transaction that involves two or more resources, or that is distributed across multiple servers. The transaction logs normally reside in the file system if you did not change the default configuration.
Besides the data mentioned above we now have a slight difference between the usage of only Standard applications (BPMN) or Advanced applications (BPEL, SCA). For Standard the above two points are everything which is touched at product runtime and everything you need to be aware of. For Advanced there is one more thing.
Data in the config directory in the BPM’s profile directory
Once you install an application containing advanced content an EAR file will be deployed. Along with the EAR installation this EAR is extracted, mapped to the cluster or server which should run the application and resources are automatically created in the background (i.e. bus destinations). All this touches files in the <Dmgr root>/config directory and are synchronized from the Deployment Manager to the nodeagents.
If you are aware of all these changes it makes things much more clear if you are thinking about a cleanup or restore.
But of cause we do not want to make things too easy. So just for the complete picture which is especially important for the restore scenario you need to be aware of another fact which holds true for all BPM releases. There are not only modifications at runtime but you may trigger modifications manually. This is
Changes to the installation binaries
So far we only talked about modifications in the profile directory. But what happens when I install an iFix or fixpack and want to revert to a state before that iFix or fixpack install?
In case of an iFix or fixpack install the following data may be modified
-Files in <BPM Install root>
And as you are installing the iFix or Fixpack with Installation Manager we also need to take care of
Changes to the Installation Manager
When installing iFixes or Fixpacks these changes are tracked in the agent data of Installation Manager. If you are fixing the Installation Manager itself you also are modifying the <Installation Manager install root>.
Hey, you got it. Now it’s becoming pretty obvious.
I want to revert back to a state earlier in time
With the above details at hand you have a time-synch database backup, a file system backup of your complete BPM install directories and profiles on all machines and a backup of the Installation manager install root and agent data. Don’t you? J
Then you can go ahead. Stop the BPM servers and database. Revert back to your above backups and start the database and servers again.
And now you are back in the past .
I want to clean up my systems from everything I did since the initial installation
There you go. Keep in mind things are getting more complex if you are running BPM Advanced applications.
For BPM Standard
You do not need to have a backup from that state. As you know from above facts for standard we only have changed content in the database and in the tranlogs so you can do the following
-Drop all tables in the BPM databases
-Recreate the tables and reinitialize default content in the databases. Refer to John’s dwAnswers post for details about reinitializing the databases.
-Clean up the transaction logs by deleting profile_root
CAUTION: Never delete tranlogs in production! You might encounter critical data integrity issue, database corruption, pending transaction might never get completed, and so on.
Isn’t this easier then restoring a backup?
For BPM Advanced
For BPM advanced you NEED a backup of the filesystem. As you remember your config files have changed and dropping and recreating the tables as for BPM Standard is not enough. So for Advanced take the steps as described under “I want to revert back to a state earlier in time”.
So what did you get out of this? Right! – I need to take backups to be safe. Go ahead and always have time synch backups of the following at hand to be able to deal with any unexpected situations:
-<BPM install root>
-<BPM profile root>
-<Installation manager install root>
-<Installation manager agent data>
And if you don’t have backups, take two of these and call me in the morning.
Your Dr. Debug