Best Practices & Recommendations

Keep Database Monitors and their related Business Processes together in their own, dedicated and separate Projects. This allows you to make changes to the monitors without having to directly affect other Clarify Projects.

Follow standard naming conventions with respect to Projects, packages, and objects. Include identifiers when naming the Database Monitor. Examples include monitor type (insert/delete/update) and database type. For example: InvoiceDBMonOracleInsert.dbMonitor

The amount of columns or data returned by the trigger on the database will depend on the nature of processing that is triggered. If the database change triggers a large integration event, requiring resources from multiple tables or a structured database schema, then it’s best to send only key columns that will drive the larger process. For example, if a change to a shipment quantity column results in the resending of an ASN, it’s a best practice to specify on the Database Monitor the shipment key information only. The key can be used to drive the generation of the larger outbound ASN sending process.

However, if the database change triggers a smaller integration event, where all the required information is contained within the table’s columns, then select all the necessary columns on the table.

Cleo provides an XML schema file (ExtolDBMonPayloadSchema.xsd) that can be used to further process the payload as needed. More information is provided in Defining Database Monitors.

Use Failover Precaution

Use the GetDatabaseMonitorEntries Business Process task to pull any trigger events that may have happened during a failover. This is a precautionary step, as there shouldn’t be any lapse in processing activity even when failover occurs in a working Clarify Server Cluster environment. Using the Process Scheduler allows the process to run on a scheduled basis to ensure coverage.