| Volume 2018 Issue 5 |
|
|
Logging script action using XML structures is not only easy, but rock solid.
There are in general four XML structures that should be captured: ECM data, System data, Input data, and Output data. The ECM data is information that was transferred from the imaging system to the workflow. This can be the barcode captured information or form recognitions extracted information. This XML structure can also include linked-back-data captured by the workflow to keep the ECM updated. System data is the data that pertain to the workflow. Let's say an A/P workflow, this data would be data that is not related to the invoice items, like GL coded etc. System data would be current queue or actor, previous actor, current state, previous state, and error information etc. The Input and Output data XML structures are used by the workflow item (like the Invoice) data. The Input data is the structure the form will use as defaulted/current data to show to the actor, whereas the Output data is the values that actor have selected to use. The reason for Input and Output is so the scripts can make valid decisions on what have been altered or supplied by the actor working the form. By storing those four XML structures it is very easy for the debugging team to see what have happened. Using a smart debugging tool like the NTS WFMDashboard that will even show what has be altered by either the actor or the script from step to step. For more information about the NTS WFMDashboard click here NTS invites you to get involved with workflow. We have access to professional workflow analysts that can help you map out the perfect solution for the workflow that will be most efficient since workflow is not a cookie-cutter solution. Should your project need an extra hand regarding programming the workflow, we have programmers with many years of experience that can help you too. return to top |
|
|
|
Last month we talked about using scripts and before that multiple user forms, State/Action matrix as a quick introduction to state machine workflow.
This month we will address debugging of scripts. In workflow there are many moving parts so the system needs an intelligent way to log what has happened before something goes wrong. One mistake that is commonly applied in the first implementation of a workflow using scripts is to have the script write to a log file. Logging is right but using log files is a mistake in a multi-threaded-multi-user environment. Logging should be done to a database table. The DBMS will handle all the multi user issues. Logging, to a database, can then later be used for datamining to increase the function of the workflow. One very successful way of logging is to capture a snapshot upon entering the script and another upon exiting the script. This way it is easy to determent what the script did and why it did it. Most workflows are using variables embedded in XML structures. Storing variables is as simple as storing XML structure strings in records. Fetching records per workflow ID, date and time, maybe even script name or function, and then searching the XML structure is easy and fast. See sidebar for information on XML structures. For information email us and asked about the NTS debugging tool WFMDashboard that was created for the OpenText Workflow Manager. Next month we will address Error Exception Handling. For more information on NTS see www.go2nts.com return to top |
|
Contact: Phone: US 415.461.8086 / 415.235.1566 Mail: PO Box 254807 Sacramento CA 95865-4807 Email: sales@go2nts.com TxtMsg: 4152351566@sprintpcs.com  NTS on Facebook
 NTS on Twitter
return to top |
|
|
Opt-out of newsletter, click here. return to top |
|