Hi,
I’ve been reading a lot of documents for understanding but I can’t understand it, I’m new with it!!
Could anybody please explain me what is the difference between the Process Engine Database and Process Audit Log Database, I know that both have different tables but I don’t know exactly what is the difference.
Thanks a lot! 
Hello,
As per my knowledge on wM 8.2 technical architecture ( I am sure there must be some change for the latest version),
Integration Server (IS) is the container for the PE which provides process orchestration of all business process steps including the work flow tasks steps (task engine).Process Engine (also task engine) db schema is used to store persistent or transient state information. Integration Servers log service data and documents to the IS Core Audit Log database.
Process Engines log data for webMethods-executed processes to the Process Audit Log database. Process Engine Built-In Services can be found in WmPRT package.
The Process Engine controls the run-time execution of business processes. The Process Engine is a webMethods Integration Server package that you install on every Integration Server that is used to run steps in a business process.
ProcessAudit => Process audit log data (Process data)
ProcessEngine => IS core audit log data (Services, Documents).
Also there is a technical architecture workshop conduced by SAG training team which will give you the existing system architecture and current documentation does not cover all the aspects (as per my opinion).
Thank for your explanation!!
That means… when I Build and Upload a process, all that information(process, steps, documents, services,etc) are going to be saved in 3 different schemas(Process Engine DB, IS Core Audit Log DB and Process Audit Log DB) in its respective schema for every kind of information.
Thanks again!
What is your webMethods version? For BPM there is change in tables names from v8 to v9.6.
After build and upload, the BPM model and instances sits in the table names starting with PRA_*****
Service auditing sits in WMSERVICE table
For document I guess it must be WMDOCUMENT
Check the below link
Hi,
my point of view:
IS Internal contains the IS internal configuration data like scheduler definitions et al.
(Tablenames start with "IS_")
IS Core Audit contains the runtime information of IS like error log, session log, security log, services log
(Tablenames start with "WM")
Process Engine contains the Design part of the Processes (generated by "Build and Upload" or modified via MonitorUI
(Table names start with "PRT")
Process Audit contains the Information about process instances, step instances, their status and iterations (iteration counts)
(Tablenames start with "WM". This will change to "PRA_" in the current releases")Prior to 8.2 all these part were bundled in one Product “IntegrationServer”, after 8.2 this was splitted into two Products “BPM” (ProssEngine) and “Integration Server” (IS Internal and IS Core Audit).
Product means the Products in DatabaseConfigurator.
Unfortunately the ProcessAudit scripts refer to the IS Core Audit scripts at some points to log the process and step errors in a common error log.
There have been some modifications in the last wM releases to separate them completely, but I am not sure in which one exactly.
Therefore I would suggest to place both products in one shared DB schema to avoid havocs (at least up to wM 9.7).
Just to be sure.
Regards,
Holger
My webMethods Version is 9.6 and my tables start with PRA… I’m Testing for improving my understanding!
Thanks for your help!
Thanks Holger von Thomsen
I’m moving on the right way!!
Regards!
Hi Alex,
The simplest response to your original question is:
The Process Engine database is the internal database that the Process Engine uses to store process instance state in real-time. It is purely internal (i.e. directly accessed by the services in the WmPRT package), and is not meant to be accessed by users. The table names do indeed start with PRT. But you should not interact with them directly.
The Process Audit database is a more public database with multiple uses:
It holds the metadata about all process models that have been “built-and-uploaded” from Designer or the command-line. This metadata includes multiple tables that hold process, version, step, transition, and quality of service information. These tables generally are named WMPROCESS*DEFINITION.
It holds the near-real-time logged information from process instances (and their steps, transitions, etc.). This logging is emitted by the Process Engine via audit messages, and the amount of information stored is settable via the “Logging Level” setting for each process type. It can include: process instance status, step status, transition status, values of custom-logged fields, errors, activity messages, control action audit information like pause/resume of instances, etc. These tables do indeed start with PRA_ in version 9.6 and above.
Note that the audit data can be written from Process Engine to the database either synchronously or asynchronously (this is a setting in IS). So the audit data may be slightly behind the “true” status of the process instances which is stored privately in the Process Engine database above.
The Monitor application in MWS has two parts. The Administration > Business > Business Processes pages to enable/disable/select logging level, etc. accesses the metadata tables. The Monitoring > Business > Process Instances pages access the instance data for running processes. So all monitoring of processes depends on the Process Audit database.
The public services in the WmMonitor package likewise access the Process Audit tables (both metadata and instance data). In fact the MWS Monitor application is built using these services.
Finally, it should be noted that the ability to audit log Documents and Services has always been distinct from audit logging processes. And as of 9.6, the schemas for their logging were separated out into separate scripts as part of “ISCoreAudit” rather than ProcessAudit.
I hope this clarifies.
-Michael
Hi Michael,
I really thank you for solving my doubt!
everything is clear now!
Thanks to all!
best regards!
-Alex
Thanks Michael,
Very useful information.
Regards,
Manikumar