This documentation applies to the 8.1 version of Remedy Action Request System, which is in "End of Version Support."

To view the latest version, select the version from the Product version menu.

Testing and debugging workflow

After you are logged onto BMC Remedy AR System with a client using the debug queue, and you have the workflow debugger running, you can take actions in the client and observe the results with the workflow debugger. For more information on configuring the server, see Configuring the server for debugging workflow.

This section describes how to use some debugger commands to get you started, and describes some example commands and output. The examples in this section assume you created some sample workflow as described in Preparing to use the workflow debugger.

Check the current location (cl)

This command causes the workflow debugger to report the current location in the workflow.

  • Issue the "current location" (cl) command before taking any action with the client to verify that the client is at an idle state. For example:

    Command: *cl*
    Current Location:
    Idle...

    The current location is listed as Idle, meaning that no workflow is currently executing.

  • In the browser, open an entry in the form you want to test. Modify the entry, for example, by changing the content in the Short Description field, and then click Save.
    The browser stops and appears frozen. This occurs because workflow, which executes on modify, has started because of the modification to the test form, and the debugger has halted the workflow.
    Now when you issue the clcommand, the debugger reports a new current location. For example:

    Command: cl
    Current Location:
    (pre-API) ArSetEntry

    The current location is listed as (pre-API) ArSetEntry. This indicates that an API call that will cause workflow has been issued.

Locations where the debugger stops workflow

By default, the workflow debugger stops workflow in the following locations:

  • Beginning of the API call (pre-API)
  • Before a filter qualifier (pre-Qual)
  • Before each Phase 1 action (Phase 1)
  • Before each Phase 2 action (Phase 2)
  • Before each Phase 3 action (post-API)
  • At the end of the API call (Idle)

The workflow debugger can also return Idle if no workflow is running, or Busy if workflow is currently executing.

You can disable each of these stopping points by setting the debug mode. See Setting the debug mode (sm, sma, and smc). For more information about filter phases, see the Workflow Objects section.

Step through workflow (s)

The step command (s) causes the workflow action to move forward one step at a time. At each step, the debugger reports the current location. You can continue stepping through the workflow with the step command until the debugger reports that you have reached the idle state again. In the case, the client logged into the debug queue has completed the workflow action.

Note

If you spend time examining the workflow debugger output, the browser might time out during debugging.

You can also issue the finish command (fi ) to complete the workflow without observing each step.

The following example output shows a series of step commands with example output:

Command: *s*
Current Location:
(pre-Qual) ArSetEntry->DebugTestcase1_2->DebugTestcase1_2:Filter Message on Submit
Command: *s*
Current Location:
(Phase 1) ArSetEntry->DebugTestcase1_2->DebugTestcase1_2:Filter Message on Submit-
		>action #0 (Set Fields)

Command: *s*
Current Location:
(Phase 1) ArSetEntry->DebugTestcase1_2->DebugTestcase1_2:Filter Message on Submit-
		>action #1 (Message)

Command:

Understanding the current location output

The current location is specified in the following format:

(stage) API_call->SchemaName->FilterName[else_path]->WF_Action_No (ActionName) [Deferred]
  • Stage — The workflow stopping point, such as pre-API, Pre-Qual, Phase 1, and. so on
  • API_call — The name of the API call
  • SchemaName — The name of the current form
  • FilterName — The name of the executing filter
  • [else_path] — Appears only when the workflow is executing the Else Actions
  • WF_Action_No — A decimal, indicating the workflow action number
  • ActionName — What the action is, for example, Set fields, Message, and so on
  • [Deferred] — Appears only when the action will be deferred to a later phase of workflow (usually for a Push Fields action)

Not all information is available or relevant at all stages.

Actions you can take while stepping through workflow

While stepping through workflow with the step command, you can also get field values, set field values, finish the workflow, change a qualification, and so on.

Get field values (gf)

In this example, the workflow debugger stops at a Set Fields action, and the user then enters a GetFieldValueList (gf ) command with a stack depth of 0.

Command: *s*
Current Location:
(Phase 1) ArSetEntry->DebugTestcase1_2->DebugTestcase1_2:Filter Message on Submit-
		>action #0 (Set Fields)

Command: *gf*
Stack depth ? (0):

APIWfdGetFieldValues  results
ReturnCode:  OK
Field Value List : 1 items
Field Value Struct:
Field Id : 8
Value:  (char)   aaa
Field Value List : 0 items
Status List : 0 items

Command:

The gf command returns the field ID 8, which is the Short Description field, and the value of the field, which in this case is aaa. The workflow debugger returns both the transaction field value list and the database field value list. In this example, there was only the transaction list so it was the only one displayed.

Set field values (sf)

The workflow debugger allows you to modify entries in the field value list.

In the following example, the user issues the SetFieldValueList (sf ) command. The workflow debugger requests values in both the transaction list and the database list.

Setting field values is restricted to fields that are already in the list, and you cannot change the data type. In this example, the user can only change field ID 8 and must use a character value, in this case, sam.

Command: *sf*
Field/value pairs to set in transaction list:
Number of field/value pairs (0): *1*
Field id: *8*
Datatype Null/Key/Int/Real/Char/Diary/Enum/Time/Bitmask/Byte/Decimal/attach/
currency/date/timeofday/join/trim/control/Table/Column/ulong/
coords/view/display (0-14, 30-34, 40-43) (0): *4*
Char Value (): *sam*
Field/value pairs to set in database list:
Number of field/value pairs (0):

APIWfdSetFieldValues  results

Command: *fi*
Current Location:
Idle...

After setting the field, the user issues the Finish API (fi ) command, to allow the workflow to complete without any further stops by the debugger.

In this example, the person running the workflow debugger could now check the record in the test form and see that the value of the Short Description field was changed from aaa to sam.

Setting the debug mode (sm, sma, and smc)

While stepping through workflow or at the idle state, you can set the debug mode to 0 to prevent the debugger from stopping the workflow during the API calls that are made later.

When you issue the sm command, follow prompts to select the appropriate stopping points.

You can also use the command set mode all (sma) to set all default stopping points, and set mode clear (smc) to clear all stopping points.

Observing a sequence of workflow actions (li)

Use the List Stack (li ) command to see the sequence of filters that led to the current location in the workflow. This command causes the debugger to walk back up the stack, printing current locations until it reaches the Idle state.

In the following example output, the workflow debugger user steps through some workflow with a filter that contains the Push Fields action in (DebugTestcase1_1:FilterPushTo2_1 ). As a result, a second filter fires (DebugTestcase1_2:Filter Message on Submit ).

Command: *s*
Current Location:
(pre-Qual) ArSetEntry->DebugTestcase1_1->DebugTestcase1_1:FilterPushTo2

Command: *s*
Current Location:
(Phase 1) ArSetEntry->DebugTestcase1_1->DebugTestcase1_1:FilterPushTo2->action #0 (Set Fields)

Command: *s*
Current Location:
(Phase 1) ArSetEntry->DebugTestcase1_1->DebugTestcase1_1:FilterPushTo2->action #1 (Push Fields) -

Command: *s*
Current Location:
(Phase 1) ArSetEntry->DebugTestcase1_1->DebugTestcase1_1:FilterPushTo2->action #2 (Set Fields)

Command: *s*
Current Location:
(Phase 2) ArSetEntry->DebugTestcase1_1->DebugTestcase1_1:FilterPushTo2->action #1 (Push Fields)

Command: *s*
Current Location:
(pre-Qual) ArSetEntry->DebugTestcase1_2->DebugTestcase1_2:Filter Message on Submit

Next, the workflow debugger user issues the*List Stack* (li ) command.

Command: *li*
Idle...
(Phase 2) ArSetEntry->DebugTestcase1_1->DebugTestcase1_1:FilterPushTo2->action #1 (Push Fields)
(pre-Qual) ArSetEntry->DebugTestcase1_2->DebugTestcase1_2:Filter Message on Submit

The output from the li command shows that, starting from an idle state, the workflow then issued an ARSetEntry API call, which caused DebugTestcase1_1:FilterPushTo2 to be invoked. It in turn executed a Push Fields action that caused DebugTestcase1_2:Filter Message on Submit to be invoked.

Creating and using breakpoints (bp, bl, bc, bx, and g)

If you already know approximately where you want the workflow to stop, you can create a breakpoint to avoid the need to step through all the stages and phases of each filter.

You can create local or remote breakpoints. With local breakpoints, the client walks through the workflow, checking each step whether the breakpoint has been reached. With remote breakpoints, when the debugger sends the run command to the server, server runs the workflow to the breakpoint before returning control to the client. Therefore, using a remote breakpoint reduces the network traffic between the debugger client and the server.

You can also combine local and remote breakpoints. In that case, issuing the Go (g) command causes the debugger to run to the next local breakpoint. Issuing the Run (r) command causes it to run to the next remote breakpoint.

The following table lists local and remote breakpoint commands.

Breakpoint commands

Local breakpoint

Remote breakpoint

Command meaning

bp

rbp

Set a local or remote breakpoint

bl

rbl

Display the list of local or remote breakpoints

bc

rbc

Clear a local or remote breakpoint

bx

rbx

Clear all local or remote breakpoints

g

r

"Go" or "run" to the next local or remote breakpoint

In the following example, the user issues a breakpoint (bp) command for the example filter DebugTestcase1_2:Filter Message on Submit. This was the second filter invoked in the earlier example. The user instructs the debugger to use any schema (*) and stop in Phase 1 (4), not on the else_path, and in action number 0. (Other than the filter name, the remaining breakpoint details in this example are the default).

Command: *bp*
	BP location -
	Filter: *DebugTestcase1_2:Filter Message on Submit*
	Schema (*):
	Stage PreAPI/PreQual/Phase1/Phase2/Phase3/Escl (2-7) (4):
	Else path? (0):
	Action number (0):
	Disabled (F):
	Passcount ? (0):


To examine the list of existing breakpoints, issue the breakpoint list (bl ) command. The workflow debugger supports up to 100 breakpoints. For example:

Command: *bl*
BreakPoint 000: DebugTestcase1_2:Filter Message on Submit * (Phase 1) (if) action 0

To clear breakpoints, issue the breakpoint clear (bc ) command and specify the breakpoint number, or issue the clear breakpoint list (bx ) command to remove all breakpoints.

To run the debugger up to a breakpoint, issue the run to breakpoint (g) command (also referred to as "go"). After you issue this command, the workflow debugger does not return a command prompt, because it is waiting for the workflow to run to the breakpoint. To activate the workflow, use the client logged in to the debug queue. For example, modify an entry in DebugTestcase1_1 and save it.

When the workflow reaches the breakpoint, the workflow debugger reports "breakpoint encountered" and displays the current location. For example:

Command: *g*
*** BreakPoint #0 encountered:
Current Location:
(Phase 1) ArSetEntry->DebugTestcase1_2->DebugTestcase1_2:Filter Message on Submit->action #0 (Set Fields)

Other functions

To see a list of all functions in the workflow debugger, issue the help (h) command at the command prompt. Some additional commands you might find useful include:

  • Terminate with an error (ta) — Forces an API call to terminate with a default error value or one that you specify

Set the qualifier evaluation result(sq) — Forces the result of the qualifier evaluation to be TRUE or FALSE. For this to have an effect, you must set the qualification result before it is used. After the workflow has passed the pre-Qual stage, this command has no effect for the remainder of the API call.

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Comments

  1. Uwe Ryczek

    I tried to use the WFD against an AR (Version 8.1.02) on Solaris 10, but he never stops at breakpoints, even the single step mode dosn't work.

    If i use do the same (same workflow, breakpoints, AR Server and WFD configuration) against an AR Server on Linux it works like a charm.

    This is what i did:

    on Solaris:

    Command: ssp
    The port number of server (0):2651
    The RPC program number of Server (0):390666
    Set Server Port Status
    ReturnCode:  OK
    Status List : 0 items
    Command: bp
      BP location -
      Filter: 1_UR_Test
      Schema (*):
      Stage PreQual/Phase1/Phase2/Phase3/Escl/CMDB (0-5) (1): 0
      Else path? (0):
      Action number (0):
    Command: sm
       Begin API (T): F
       Qualifier (T): T
       Phase 1 (T):
       Phase 2 (T):
       Phase 3 (T):
       End API (T): F
       Esc Action (T): F
       CMDB (T): F
    Wfd Set Debug Mode Status
    ReturnCode:  OK
    Status List : 0 items
    Command: cl
    Current Location:
    (pre-Qual) ArSetGetEntry->2_UR_Test->1_UR_Test_pre
    Command: s
        Workflow Step
    Current Location:
    Busy...
    Command: cl
    Current Location:
    Idle...

    <new test client action>


    Command: cl
    Current Location:
    (pre-Qual) ArSetGetEntry->2_UR_Test->1_UR_Test_pre
    Command: g
    WFD Run To BPCurrent Location:
    Idle...
    Command:

     

    on Linux:

    Command: ssp

    The port number of server (0):2651

    The RPC program number of Server (0):390666

    Set Server Port Status

    ReturnCode:  OK

    Status List : 0 items

    Command: bp

      BP location -

      Filter: 1_UR_Test

      Schema (*):

      Stage PreQual/Phase1/Phase2/Phase3/Escl/CMDB (0-5) (1): 0

      Else path? (0):

      Action number (0):

    Command: sm

       Begin API (T): F

       Qualifier (T): T

       Phase 1 (T):

       Phase 2 (T):

       Phase 3 (T):

       End API (T): F

       Esc Action (T): F

       CMDB (T): F

    Wfd Set Debug Mode Status

    ReturnCode:  OK

    Status List : 0 items

    Command: cl

    Current Location:

    (pre-Qual) ArSetGetEntry->2_UR_Test->1_UR_Test_pre

    Command: s

        Workflow Step

    Current Location:

    (Phase 1) ArSetGetEntry->2_UR_Test->1_UR_Test_pre->action #0 (Felder einstellen)

    Command: s

    Current Location:

    (pre-Qual) ArSetGetEntry->2_UR_Test->1_UR_Test

    Command: s

        Workflow Step

    Current Location:

    (Phase 1) ArSetGetEntry->2_UR_Test->1_UR_Test->action #0 (Felder einstellen)

    Command: fi

    <new test client action>

    Command: cl

    Current Location:

    (pre-Qual) ArSetGetEntry->2_UR_Test->1_UR_Test_pre

    Command: g

    WFD Run To BP*** BreakPoint #1 encountered:

    Current Location:

    (pre-Qual) ArSetGetEntry->2_UR_Test->1_UR_Test

    Command: fi

     

    Is there a Solaris AR Server/WFD issue known?

     

     

    Jan 29, 2015 03:45
    1. Prachi Kalyani

      Hello,

      Thank you for your comment. I will verify this with the concerned SME and get back to you.

      Thanks,

      Prachi

      Jan 29, 2015 05:30
    1. Prachi Kalyani

      Hello,

      Thank you for your comment. This is a known issue with the Workflow debugger and is documented on BMC Remedy AR System server known and corrected issues topic with the Issue ID SW00465846.

      Thanks,

      Prachi

      Feb 24, 2015 02:30
      1. Uwe Ryczek

        Hello Prachi,

        thanks for adding this to the known and corrected issues of AR Server Version 8.1.

        As i can see SW00465846 is an very old defect (Version 7.6.04 SP4) and "Target Release Version" is set to "Future Patch Release".

        Do you have any information if someone is actively working on that issue and a patch will be available?

        Thanks,

          Uwe

         

        Feb 24, 2015 03:02
        1. Prachi Kalyani

          Hello,

          Please contact BMC Customer Support, for more information on this issue.

          Thanks,

          Prachi

          Feb 24, 2015 05:30