This is an old revision of the document!
Bizweaver provides a method to trigger a workflow from a Post Execute SQL stored procedure (for example SAP SBO_SP_PostTransactionNotice) in an SAP database (SQL or Hana). From the SAP stored proc, trigger instructions are inserted into a Bizweaver staging table and then immediately into a queue via a 'listener' (installed with Bizweaver) as a trigger request. Based on the target workflow's availability, the listener processes the request, triggering the workflow via the Bizweaver Commander.
All trigger set-up, management, and monitoring can be done via the Bizweaver user interface without the need to manually add or change SQL code in SAP.
Triggers are created from the workflow design window.
Upon selecting a connection to an SAP database in the trigger set-up panel, the Procedure, Document, and Parameter select menus are automatically populated with the SAP stored proc names, document table and field names respectively.
Once a Bizweaver user-defined variable has been assigned and saved as part of a trigger, it can not be deleted. To delete or change the variable (using the variable tool), the trigger must first be deleted. Triggers are very disposable. Deletion simply removes the code for that trigger from the SAP proc and it's very easy to add a new trigger.
When the five required fields plus optional parameters are entered and the workflow is saved, Bizweaver:
Bizweaver creates only one staging table per SAP database.
The code inserted into the SAP stored procedure is surrounded by comments and is easy to identify by the trigger ID. It should not be tampered with. When the SAP stored procedure is called (ex. SAP SBO_SP_PostTransactionNotice), resulting from an action in SAP, a record is inserted into the staging table including the SAP document SQL table name and DocEntry value.
Do not tamper with the SQL code Bizweaver inserts into the SAP post-execute stored procs
Example of the trigger SQL code that gets inserted into the SAP stored procedure:
The workflow is triggered by the listener, which performs these actions:
The details of saved trigger set-ups can be viewed, and the triggers enabled/disabled or deleted as follows:
When a trigger is disabled the listener ignores it when it moves trigger records from the staging table in SAP to the trigger request queue in Bizweaver. It then deletes it after the latest enabled trigger requests have been copied to the request queue in Bizweaver.
More than one trigger can be configured for a workflow.
Saved and unsaved triggers (including those where the setup is incomplete) are available in memory while designing the workflow. These can be accessed via the … icon in the upper right corner of the trigger set-up panel. However, the workflow cannot be saved with incomplete trigger set-ups. Bizweaver will require incomplete set-ups to be completed or removed before the workflow can be saved.
Clicking the trashcan icon in this window does not delete saved triggers from the Bizweaver database or the SAP stored procs until the workflow is saved again.
As of the 2.9.x release, saved triggers can not be modified. The trigger must be deleted via the user interface and a new one created.
A view to queued trigger requests is provided as a tab in the workflow and Bizwever main trigger listing windows.
Typically requests are not in the queue long enough to be seen because of the speed of processing. However, if targeted workflows are not available (because they are running) you may see requests for those workflows queueing up.
When you can see trigger requests in the request queue window, they will reflect one these statuses:
You have the ability to put a Hold (see the above screenshot) on processing queued requests. Clicking Hold allows trigger requests to queue but prevents them from triggering workflows until Resume is clicked.
The Hold feature may be useful when workflow processing via triggers needs to be stopped temporarily for any reason and gives an operator the chance to review the details of a queued request, delete the request, disable triggers if necessary, or resume processing.
The details of a queued trigger request can be accessed by clicking the … icon next to a request in the request listing.
In test mode, for triggers with parameters, the user will need to provide mock parameter values.
Upon running a test, a dialog is presented to select the saved trigger set-up (there could be more than one for a single workflow) and provide values for the configured parameters.