Troubleshooting Issues for Dynamic Assignment

This chapter describes the troubleshooting steps for dynamic assignment issues.

To troubleshoot issues when the Workflow Monitor Agent is started for the proper group

Dynamic Assignment Manager is based on triggers. In order for Dynamic Assignment to assign, the database triggers (generated by running the Generate Triggers Server task) need to be active. If the triggers are not active, whenever a record is created or updated, the Assignment Manager will not be invoked to assign the records.

  1. Determine if the Assignment Policies are active.

    For performing correct assignment, the Assignment Policies needs to be active. Verify that the Assignment Policies are active by navigating to Site Map, 'Assignment Administration', 'Assignment Policies'. Check if for the Assignment policies specified, the "Activation Date" and "Expiration Date" fields are populated correctly as required. You can run the following query directly in the database to identify all the Active or Expired policies under the Default "Assignment Group".

    SELECT NAME, ACTIVATE_DT, EXPIRE_DT FROM S_ESCL_RULE WHERE GROUP_ID IN (SELECT ROW_ID FROM S_ESCL_GROUP WHERE NAME = 'Assignment Group')

  2. Verify that the Generate Triggers server task has been run to drop and recreate the database. triggers

    Run the Generate Triggers server task with the following parameters:

    Drop Triggers:

    EXEC = True

    Remove = True

    Generate Triggers:

    EXEC = True

    Remove = False

    For the parameters required while running the Generate Triggers Siebel Server task in Siebel version 7.0.4 and higher, refer to Alert 506: Running the Generate Triggers Siebel Server task in Siebel eBusiness Applications version 7.0.4 and higher on SupportWeb.

  3. Verify that the requests are being inserted into the S_ESCL_REQ table.

    Query the S_ESCL_REQ table in the database to verify that new requests are inserted into this table whenever records corresponding to the active Assignment Policies are inserted or updated. The requests should be processed by the Workflow Monitor Agent running for the appropriate group (by default, all the standard assignment policies are defined under the Assignment Group).

    If however, the Assignment Manager does not assign as expected, or the Workflow Monitor Agent running for the Assignment Group errors out, follow the steps outlined in How to generate detailed log files for Workflow Monitor Agent in Siebel 7.x (Doc ID 476710.1) on My Oracle Support and log a service request providing the Workflow Monitor Agent log file. For information on how to start the Workflow Monitor Agent in Siebel 7, see How Do You Create and Start a Workflow Monitor Agent in Siebel Version 7.x and 8.x (Doc ID 476425.1).

To troubleshoot issues when Dynamic Assignment is being performed but is slow due to the huge dynamic request queue

As dynamic assignment requests are based on underlying database triggers, the latest request is put at the end of the queue. If the queue is huge, then the Workflow Monitor Agent processing the requests will take some time to reach the latest request in the S_ESCL_REQ table. Customers can monitor the S_ESCL_REQ table to get more information on the Dynamic Assignment requests.

  1. Determine the current Assignment Manager request.

    Run the following SQL in the database to determine the Assignment Manager request queue. This will list the total number of requests along with the first and last request Id's in the S_ESCL_REQ table for the "Assignment Group".

    SELECT COUNT(*) "Count", MIN(REQ_ID) "First Request", MAX(REQ_ID) "Last Request" FROM S_ESCL_REQ WHERE GROUP_ID = (SELECT ROW_ID FROM S_ESCL_GROUP WHERE NAME = 'Assignment Group')

  2. Query to determine the rows for existing policies (including active and expired).

    SELECT a.NAME, a.ROW_ID, COUNT(b.RULE_ID)

    FROM S_ESCL_RULE a, S_ESCL_REQ b

    WHERE a.ROW_ID = b.RULE_ID

    GROUP BY a.NAME, a.ROW_ID, b.RULE_ID

  3. Query to determine the rows for expired policies.

    SELECT a.RULE_ID, b.NAME, COUNT(a.RULE_ID), b.EXPIRE_DT, b.SUB_TYPE_CD

    FROM S_ESCL_REQ a, S_ESCL_RULE b

    WHERE a.RULE_ID = b.ROW_ID and b.EXPIRE_DT < GETDATE()

    GROUP BY a.RULE_ID, b.NAME, b.EXPIRE_DT, b.SUB_TYPE_CD

    For Oracle, use SYSDATE instead of GETDATE()

  4. Query to determine the rows for deleted policies.

    SELECT RULE_ID, COUNT(RULE_ID)

    FROM S_ESCL_REQ a

    WHERE not exists (SELECT ROW_ID FROM S_ESCL_RULE b

    WHERE a.RULE_ID = b.ROW_ID)

    GROUP BY RULE_ID