Workflow Best Practices April 3, 2018 Gayla Jenner – Everett Public Schools

Agenda Troubleshooting Tools Working with Workflow Database Tables What’s New in 7.9.10 Store ADODB Connection Info on Server

Troubleshooting Tools Use the Internal Data to evaluate all the tables, fields and values being supplied to your workflow model

Troubleshooting Tools Attach to your instance that generated an error, and execute the activities individually

Troubleshooting Tools For scheduled models, you might need to send it through again so that your variables and other data values are refreshed

Model Ending Activities No Transition – necessary when you have conditional transitions Error – necessary for everything Not Accepted/Rejection – necessary when there are approval activities in the model The only one necessary for ALL models is ERROR HANDLER

Workflow Database Tables WF_MODEL Stores primary model information WF_SCHEDULE Stores schedule information for scheduled models WF_QUEUE Queues instances triggered by database updates WF_INSTANCE Tracks instances being processed by the workflow engine WF_QUEUE – All instances start in the wf_queue table before being submitted to the workflow processing engine. WF_INSTANCE – Tracks each instance as it is processed through the workflow model. Based on the status and wf_next date will determine when it is processed next in the workflow engine. WF_INSTANCE_VAR – Tracks model variables for each instance, depending on when or if your model uses variables. WF_HISTORY – Tracks each activity processed by the workflow engine. WF_INSTANCE_VAR Tracks variable info for each instance, when applicable WF_HISTORY Tracks activities processed by the workflow engine

Refreshing TEST after a DB Update Find all (A)ctive models, excluding standard models required to run jobs, rebuild security and build attachments; set status to (I)nactive Wf_model Deactivate all scheduled models; set status to (I)nactive Wf_schedule Remove all instances associated to inactivate models from the workflow engine; update status to (H)old Wf_instance Remove all instances from the workflow task list; update to approved status (Y) Wf_history Optional Clear NUUPUS email addresses by either removing email or replacing with default address Us_usno_mstr

Cleaning Up Recent addition to find out how large workflow tables are growing If deciding to delete old data, go back one page and delete data from tables from step 4 to step 1 Recent contribution to Slack - to find out how large workflow tables are growing

Get to Know DBCustom.xml Examples: FA – Fixed Assets fa_idnt por_rec_dtl poi_item_dtl HR – Employee Master hr_empmstr hr_emppay hr_pcntble HR – EO Transactions hr_trnsreq Joins additional tables, relationships and fields that can be used in each model instance. If there are no relationships built in the dbcustom file, then the data fields from your selected table object is the only data you will have in your model. Also used to define fields used in webforms.

New in 7.9.10 - Send Emails to a Group No longer need to “hard code” recipient names as Text/Lists

New in 7.9.10 - Send HTML Emails Study up on your HTML coding!

Optimal Workflow Settings – prior to 7.9.10 Splitting models to multiple workflow servers is applicable in versions BELOW 7.9.10.

Optimal Workflow Settings – beginning 7.9.10 In 7.9.10 version, workflow runs on 1 server only. MaxThreads give you more processing threads, 11 is default giving you 5 processing threads, go to 16 to get 10 processing threads.  For EmailSleepMinutes the lowest is 5 minutes and that determines how often it looks for email responses. 

Multi-Threaded Workflow in 7.9.10 The five dedicated threads have a specific job to perform for each type of job listed below: The processing queue is just an internal list of instances/records that the remaining five [Default, 15 MAX] threads will work on. Each of these threads will pick a record from the list/queue and process it to its end. The thread will then return to pick the next record (if any) to process. This cycle will continue until there are no more records left in the “Processing Queue”. Then the thread will sleep for the set interval. After wake up, each of these threads will check if there are any records in the “Processing Queue”. If none, then the thread will go back to sleep. As each thread takes different amounts of time to finish its assigned [fixed or dynamic] task, they will be done with their task at different times and will sleep at different times. In other words, after a few minutes, not all threads will be sleeping or working at the same time. As each thread takes different amounts of time to finish its assigned [fixed or dynamic] task, they will be done with their task at different times and will sleep at different times. In other words, after a few minutes, not all threads will be sleeping or working at the same time.

DBCustom.xml File Recognition Changes When you make a dbcustom.xml change a data processing restart is not required any more. Go to workflow designer – tools – import file settings which populates the dbcustom file in the database and if you run the SQL Query above from the Admin Console you can click View Data under the data column to view the updated XML file it uses.  (NOTE: This does require one of the earlier patches for it to work, does not work with the base 7.9.10 installer; need to load on all workstations running workflow)

Store ADODB Connection Info on Server Store your application server name and connection information in one place on your workflow server

Store ADODB Connection Info on Server Sample WF Model to collect server information for script activities