Laser­fiche Work­flow is a won­der­ful tool for au­tomat­ing busi­ness processes within your or­ga­ni­za­tion, yet some­times even the most thought-through work­flows can func­tion in un­ex­pected ways. Al­though some of these prob­lems may be related to hard­ware or soft­ware con­fig­u­ra­tion, a large number of them are due to non-op­ti­mal work­flow design.

Here are some sug­ges­tions for de­bug­ging your work­flow designs when:

• Your work­flow is not working as ex­pected.
• Your work­flow is not start­ing.
• Too many in­stances of the same work­flow are start­ing.

In order to di­ag­nose your problem, you can use three dif­fer­ent tools, each of which is de­scribed in more detail in the sec­tions below:

• Laser­fiche Work­flow 8.3 search.
• Sub­scriber trace.
• Work­flow sta­tis­tics report.

Sce­nario 1: Your work­flow is not working as ex­pected

When in­ves­ti­gat­ing why a Laser­fiche Work­flow de­f­i­n­i­tion (a Work­flow design) is not working as ex­pected, it is im­por­tant to first find the work­flow in­stance that per­tains to the spe­cific entry. The easiest way to do this is using Laser­fiche Work­flow 8.3’s built-in search func­tion­al­ity. Simply nav­i­gate to the “Search” pane in the Work­flow De­signer and con­fig­ure a search for the most recent running in­stance of the work­flow in ques­tion.

Example: You have created a work­flow (named “Work­flow 1″) that is sup­posed to route in­voices from the “In­voices – In­com­ing” folder to the “In­voices – Ap­proved” folder after they are ap­proved by Pur­chas­ing and by Ac­count­ing. You realize that the invoice you just scanned into Laser­fiche is not showing up in the “In­voices – Ap­proved ” folder, even though it has dis­ap­peared from the “In­voices – In­com­ing” folder.

After search­ing for the most recent in­stances of Work­flow 1, you will see the fol­low­ing results:

Click image to view larger in a new window.

Iden­tify the work­flow in­stance that you are in­ter­ested in and dou­ble-click it to see its “In­stance Details”. Each tab dis­plays dif­fer­ent in­for­ma­tion that you can use for trou­bleshoot­ing.

• The “Work­flow” tab pre­sents a color-coded, visual rep­re­sen­ta­tion of where the doc­u­ment is in the actual work­flow. Dif­fer­ent colors signify dif­fer­ent things (i.e. green cor­re­sponds to “Com­pleted”, blue to “Running” and yellow to “Has Warning”). This view is helpful in iden­ti­fy­ing where a doc­u­ment is stuck inside a work­flow. You can then view the ac­tiv­ity prop­er­ties and iden­tify any pos­si­ble con­fig­u­ra­tion errors.For example, in this work­flow, you can see that the par­tic­u­lar invoice has been ap­proved by Pur­chas­ing and is now waiting to be ap­proved by Ac­count­ing before it moves to the next steps. 
• The “Entries” tab dis­plays all of the entries that the work­flow in­stance has in­ter­acted with. This tab is helpful in check­ing that the work­flow is only pro­cess­ing the ex­pected entries. In this case, the Wolf­skin, Inc. invoice is the only one that this work­flow in­stance has in­ter­acted with so far.
  

  Click image to view larger in a new window.

• The “Ac­tiv­i­ties” tab lists in­for­ma­tion about all of the ac­tiv­i­ties that have thus far been com­pleted in this in­stance of the work­flow. This can help you see exactly what has hap­pened and if it matches your ex­pec­ta­tions. The” Ac­tiv­i­ties” tab is useful when in­ves­ti­gat­ing the du­ra­tion of a work­flow or how many times an it­er­a­tion, like a “For Each Value” ac­tiv­ity, was per­formed. You can see a list of all ac­tiv­i­ties Work­flow went through or just the ones that took a rel­a­tively long time.
  

  Click image to view larger in a new window.

• • The “Mes­sages” tab gives you in­for­ma­tion about all the errors and warn­ings that have oc­curred while this work­flow in­stance was running. If your work­flow ter­mi­nated or has any warn­ings, this is the place that will show you why.
  

  There are three types of mes­sages that can appear in this tab:

  • In­for­ma­tional mes­sages do not impact the work­flow in any way, but the user may find them in­ter­est­ing when an­a­lyz­ing per­for­mance.
    For example, you have a work­flow that searches for doc­u­ments based on certain cri­te­ria and then routes them to another folder. Nor­mally, this work­flow takes ten minutes to run, but today it took three hours. You check the in­stance details and see that where it would usually find ten doc­u­ments, today it found 300.
  • Warn­ings in­di­cate that some­thing oc­curred that im­pacted the ex­e­cu­tion of the rule, but Work­flow was able to recover from it. Warn­ings are not fatal and the work­flow rule will move to the next ac­tiv­ity once the current one suc­ceeds.For example, if a doc­u­ment is locked when you try to set fields on it, Work­flow will log a warning, wait 5 minutes and then try again.
  • Errors occur when Work­flow can’t or is unable to handle a par­tic­u­lar issue.For example, if you try to move an entry that no longer exists, Laser­fiche Server will return an “Entry Not Found” error. Errors are usually fatal, causing the work­flow in­stance to ter­mi­nate.

  Coming back to our orig­i­nal example, we do not have any mes­sages as­so­ci­ated with that par­tic­u­lar work­flow in­stance.

  
• The “Tasks” tab dis­plays ac­tiv­i­ties that have the po­ten­tial to be long-run­ning, along with their sta­tuses. Most of the time this tab will be empty, but in this case you can see that the invoice has been ap­proved by Pur­chas­ing on the first attempt.
  
• The “Con­di­tion” tab spec­i­fies the par­tic­u­lar con­di­tions that have been eval­u­ated and if they have been met. For each eval­u­a­tion, you’ll be able to see the result and what the values were at the time.
  

  Click image to view larger in a new window.

• Laser­fiche Work­flow 8.3 allows the user to log the values of tokens at spe­cific stages in the work­flow for de­bug­ging pur­poses. To do so, you can use a “Track Tokens” ac­tiv­ity. The ac­tiv­ity can be con­fig­ured to either log all tokens or spe­cific ones. You can use it to dou­ble-check that token values are what you expect them to be. Once the ac­tiv­ity runs, you can see the recorded token values in the “Tokens” tab in the in­stance details. You have an option for seeing all values or just the ones logged at a par­tic­u­lar stage. In this case, we’re dis­play­ing all the tokens.
  

Coming back to our orig­i­nal example, Work­flow 1 seems to be running cor­rectly. The reason that the invoice is not yet in the “In­voices – Ap­proved” folder is that Ac­count­ing hasn’t ap­proved it yet. Fol­low­ing up with the ac­count­ing de­part­ment should resolve the issue.

 Scenario 2: Your workflow is not starting

One of the most common issues that users en­counter is their work­flow looking like it has not even started when it should have. When­ever you’re looking into why a work­flow did not start, look at the Sub­scriber Trace avail­able from the Work­flow Ad­min­is­tra­tion Console “Mon­i­tor­ing – Sub­scribers” node.

Using the Sub­scriber Trace you can see the results of your start­ing rules:

• If your work­flow failed to start because the start­ing rules weren’t eval­u­ated cor­rectly.
• If more than one work­flow started on the same doc­u­ment (leading to your work­flow ap­pear­ing not to have started because the entry will not end up where you would expect it).

When you open the Sub­scriber Trace, you’ll see mul­ti­ple tabs:

• Events.
• Repos­i­tory.

The “Events” tab shows you each event that hap­pened, how many start­ing rules were eval­u­ated and the results of the eval­u­a­tion. You can also view other pa­ra­me­ters that relate to the event like the type (such as Entry Copied) and the user who gen­er­ated it (such as Work­flow User), as well as how long the eval­u­a­tion took. Notice that some con­di­tions take no time at all (like the name, path and user), while others take much longer and are more ex­pen­sive because Work­flow has to call into Laser­fiche to get more in­for­ma­tion on the entry (like fields or folder counts).

You can also filter the results by dif­fer­ent Event Types or Work­flow pa­ra­me­ters.

The “Repos­i­tory” tab gives you graph­i­cal in­di­ca­tions of the number of events that oc­curred in your repos­i­tory re­cently and the current load on your Work­flow Sub­scriber. There will be a sep­a­rate tab for each repos­i­tory your Work­flow Sub­scriber mon­i­tors.

For example, a high load on the no­ti­fi­ca­tion thread would in­di­cate that the Sub­scriber has a lot of events to process which may be the reason your work­flow hasn’t started yet.

Sce­nario 3: Too many in­stances of the same work­flow are start­ing

Another case where the start­ing rules may be to blame is if you get too many Work­flow in­stances started on the same doc­u­ment. They can be sep­a­rate in­stances of dif­fer­ent rules or they can be mul­ti­ple in­stances of the same rule. The latter happens when your start­ing rulesare not spe­cific enough or are con­fig­ured in­cor­rectly.

You can check on your Work­flow Server by running a sta­tis­tics report from the “Mon­i­tor­ing – Sta­tis­tics” node in the Work­flow Ad­min­is­tra­tion Console. A sta­tis­tics report ag­gre­gates data about each work­flow:

• The number of entries that ran through each rule.
• The status of the work­flow in­stances.
• The du­ra­tion of the work­flow in­stances.

Click image to view larger in a new window.

You know there may be some­thing wrong with your start­ing rule if:

• Your work­flow ran a very large number of times. For example, you can see that the “Load” work­flow in the screen­shot above ran over 200,000 times.
• If you notice a very large number of ter­mi­nated in­stances.

As you’ve seen in the Sub­scriber Trace, for each event type, Work­flow eval­u­ates all start­ing rules as­so­ci­ated with it. In order to prevent con­flicts, you want your rules to be as spe­cific as pos­si­ble:

• If only doc­u­ments are sup­posed to trigger the work­flow, add a con­di­tion on the doc­u­ment type.
• If only spe­cific users should be able to start a given work­flow, add a con­di­tion on the user name.
• If some users are not sup­posed to be able to start a work­flow, exclude them from the start rule. For example, you should exclude the “Work­flow” user to prevent your work­flow from start­ing ac­ci­den­tally based on the action of some other work­flow.

You should also order the con­di­tions based on their cost or how long it usually takes to eval­u­ate them:

• Entry name and path con­di­tions are in­ex­pen­sive since Laser­fiche sends that in­for­ma­tion over with the no­ti­fi­ca­tion.
• Field con­di­tions can come next as they require a call to Laser­fiche to re­trieve the field values for that entry.
• Folder content con­di­tions are most ex­pen­sive since they need to cal­cu­late the number of doc­u­ments in a given folder.

You should also put the con­di­tions least likely to succeed at the top because, once a con­di­tion eval­u­ates to false, the entire rule eval­u­ates to false. In this way, Work­flow will be more ef­fi­cient since it will not always have to eval­u­ate all con­di­tions.

Narrow down which entry change events should trigger Work­flow. For example, if your Work­flow should only start when a tem­plate field is set, you can specify that.

Summary

Mon­i­tor­ing your work­flows reg­u­larly using the Work­flow Ad­min­is­tra­tion Console can give you an idea of regular pat­terns and can help you catch and di­ag­nose unusual issues quickly. Work­flow’s com­pre­hen­sive search func­tion­al­ity allows you to delve down and in­ves­ti­gate spe­cific entries and pin­point the actual cause of a problem or bug.