Setting up and monitoring the database persistence tables
Setting up and monitoring the database persistence tables is usually not required when running a published application, but may be useful at development time. When doing rule development between two test runs, you may have to reset the BPM Events tables in a database, to make sure that each test uses a clean database state and is not affected by previous runs.
First, make sure that the database user that is specified in the oebpsdb.properties file is actually registered in the database server.
You can then do a complete set-up/clean-up with the command:
setupOEBPS -c ALL
Or, if you do not have Business Process Server:
setupBPMEvents -c ALL
After this, you can start BPM Events server.
When debugging, be aware of a few useful SQL commands you can do to check the content of BPM Events database tables. Entering these commands tells you how many events are in the database, how many were processed, what is the content of the cache, etcetera. The SQL commands are:
// tells how many events are in the BP Server event queue.
SQL> select count(*) from BPMEvent;
// shows the schema (attributes) of a table (for example, BPMEvent)
SQL> desc BPMEvent;
// tells what was the last event successfully processed by BPM Events:
SQL> select * from BPM EventsEventCounter;
// tells what is the highest (latest) event ID generated, in the OEBPS event queue.
SQL> select max(event_ID) from BPMEvent;
// tells what is the content of the cache, for events initially notified via the database queue:
SQL> select * from BPMEvents_EventExtent;
// tells what events are currently scheduled:
SQL> select * from BPMEvents_ScheduledItemExtent;
