The information in this article applies to:
Product: Metastorm BPM
Version: 7.5 7.5.1
Discussion
BPM Engine Startup Sequence 1. Locale details are checked. 2. Event log access is configured. 3. An OS version check is performed. 4. Check that the engine is not already running on this machine. 5. Most registry lookups are performed at this point. 6. Attempt to open an ADO connection to the database (using database connector settings from the registry). 7. Using this ADO connection: A. Check that the database schema is of the correct version for this engine: SELECT count(\*) FROM eAlertRequest WHERE 1 = 2 B. Retrieve system configuration info from the database: SELECT eServerName, eFolderLockTimeout, eKeepAliveInterval, eDoAlertGeneration, eDeleteDeletionAlerts, eNotification, eEventHandlerFunction FROM eServer C. Retrieve info about this ADO connection, including a. DBMS name b. DBMS version c. Data source name (DSN) d. OLEDB provider name e. Version of OLEDB f. Version of OLEDB provider g. OLEDB server name h. OLEDB user name D. Check whether static role resolution is to be performed: SELECT COUNT(\*) FROM eAssignment, eUser WHERE 1 = 2 E. If the EnableMQIntegration registry setting is set to 1, check for the existence of the required MQ tables: SELECT COUNT(\*) FROM eInMQ, eOutMQ WHERE 1 = 2 F. At this point a number of updates are performed against the database within a single transaction: a. Using the DBMS name gathered earlier, the eServer table is updated. For SQL Server this will be: UPDATE eServer set eDatabaseType = N'Microsoft SQL Server' b. Based on an engine name of MBPMServer, a stored procedure call is issued: \{call esp\_remove\_marks\_for\_engine(N'MBPMServer')\} c. An entry for this engine is added to the eActiveEngine table (assuming system defaults apply): \{call esp\_add\_engine( N'MBPMServer', N'on demand', N'on demand' )\} G. The ADO database connection is closed. 8. A check is made to ensure the database connector works. Another ADO connection is made, then disconnected. 9. Now an ODBC connection is made. Using this connection: A. Retrieve info about this ODBC connection, including these parameters: a. SQL\_DBMS\_NAME b. SQL\_DBMS\_VER c. SQL\_DRIVER\_VER d. SQL\_ODBC\_VER e. SQL\_ODBC\_API\_CONFORMANCE f. SQL\_TXN\_CAPABLE g. SQL\_ODBC\_SQL\_CONFORMANCE h. SQL\_DEFAULT\_TXN\_ISOLATION i. SQL\_MULTIPLE\_ACTIVE\_TXN j. SQL\_TXN\_ISOLATION\_OPTION B. If running against Microsoft SQL Server, DTC initialization is performed via a call to DtcGetTransactionManager. C. A check is now performed to ensure that this ODBC connection is looking at the same database as the ADO database connection (passing MBPMServer as a parameter): SELECT eEngineName FROM eActiveEngine WHERE eEngineName = ? D. When running against SQL Server, a series of calls is made to the ODBC function SQLColumnsW to get full column information for each of these tables: a. eAction b. eAlert c. eEvent d. eField e. eFolder f. eForm g. eMap h. eRole i. eServer j. eStage k. eWait l. eLog m. eAttachment n. eSession o. eUser p. eAssignment E. The ODBC database connection is closed. 10. Check to see whether the engine needs to do TP logging. 11. Start the Keep Alive manager (runs in its own dedicated thread). This results in a stored procedure call being made to the database via ADO, by default every 2 minutes. The procedure is esp\_keep\_engine\_alive and the name of the engine is passed (e.g. MBPMServer). 12. The infrastructure to support calls to JScript.NET is started up. Depending on precompilation settings in the registry, this may result in database lookups against the eAttachment table. 13. The ECL is started. If the settings in the remoting.config file configure ECL to listen on TCP or IPC, a remoting listener is started up. 14. The procedure manager is started up. This is used to handle asynchronous MBPM functions (e.g. %ScriptAsync). 15. If the EnableMQIntegration registry setting is set to 1, the MQ definitions are loaded from the database via ADO: Select eInQueueName, eQueueSystem, eEworkHost, eQueueSource, eCredentials, eAuthenticationProcess, eClientType, eMapName, eStageName, eActionName, eParams from eInMQ (this is done using its own ADO connection that is then dropped). 16. The alert generator component is started. 17. The event manager component is started. At this point the engine is started. Note that components such as the procedure manager, alert generator, and event manager spin off one or more threads of their own that may also make communications of their own (e.g. to the database, to MS Word). In the case of the alert generator and event manager, some or all of their database communications are ODBC-based. If running against SQL Server this also implies usage of DTC.
