Adding Event Trigger Scripts: Procedures

This example describes how to create a general event trigger script that is used to update a workflow attribute. This general event trigger script walks through all of the different types of data that are flowing through the workflow (the work package) and locates the attributes RecArray. It then walks through all of the attributes in the RecArray, locates the one that you want to update, and updates the attribute by saving new data from the workflow.

1. Orphan WFMain:WFRoot:CallbackEventScripts:GeneralCallbackScripts in your custom module's OSpace, and name it GeneralCallbackScripts.

2. In the GeneralCallbackScripts object, set the value of the fEnabled feature to TRUE.

3. In the GeneralCallbackScripts object, create a String feature, and name it fChangeAttribute.

4. Set the value of the fChangeAttribute feature to Update Workflow Attribute.

5. Create a script, and name it ChangeAttribute.

6. In your custom module's Globals object, run the BuildOSpace() script.

7. Save and export your OSpace, and then restart the Livelink Builder.

The GeneralCallbackScripts object is registered in WFCBGeneralSubsystem, and the Event Scripts tab is exposed in the Content Server interface.

You have provided the information necessary to display the Update Workflow Attribute option on the Event Scripts tab in the Content Server interface. Now, you must provide the code that the ChangeAttribute() script requires to perform the operation.

You can use breakpoints to debug event trigger scripts in the same way that you use breakpoints to debug other scripts in the Livelink Builder; however, placing a breakpoint in an event trigger script always returns a workflow error. Some calls in the event trigger scripts (especially those that use WAPIWORK) will fail if you have added breakpoints. When you finish debugging event trigger scripts, you must remove the breakpoints that you have added.

Another way to debug callback scripts is to send messages to the Builder's Debug window using the Echo function. For more information about the Echo function, see the Livelink Builder Developer's Guide.

This example describes how to create a performer event trigger script that is used to locate a workflow attribute named username. This performer event trigger script locates the user associated with this attribute and assigns the next workflow step to them.

1. Orphan WFMain:WFRoot:CallbackEventScripts:PerformerCallbackScripts in your custom module's OSpace, and name it PerformerCallbackScripts.

2. In the PerformerCallbackScripts object, set the value of the fEnabled feature to TRUE.

3. In the PerformerCallbackScripts object, create a String feature and name it fChooseUser.

4. Set the value of the fChooseUser feature to Choose User.

5. In the PerformerCallbackScripts object, create a Script and name it ChooseUser.

6. In the modulename Globals object, run the BuildOSpace() script.

7. Save and export your OSpace, and then restart the Livelink Builder.

The PerformerCallbackScripts object is registered in WFCBPerformerSubsystem, and the Event Scripts tab is exposed in the Content Server interface.

You have provided the information necessary to display the Choose User option on the Event Scripts page in the Content Server interface. Now you must provide the code that the ChooseUser() script requires to perform the operation.

This example describes how to create a submap event trigger script that is used to define a Sub-workflow map and save the map definition in WAPI. This map definition instructs Content Server to assign the same task to each Content Server user in the user list.

1. Orphan WFMain:WFRoot:CallbackEventScripts:SubmapCallbackScripts in your custom module's OSpace, and name it SubmapCallbackScripts.

2. In the SubmapCallbackScripts object, set the value of the fEnabled feature to TRUE.

3. In the SubmapCallbackScripts object, create a String feature and name it fsubworkflow.

4. Set the value of the fsubworkflow feature to Generate Sub-workflow.

5. In the SubmapCallbackScripts object, create a Script and name it subworkflow.

6. In the modulename Globals object, run the BuildOSpace() script.

7. Save and export your OSpace, and then restart the Livelink Builder.

The SubmapCallbackScripts object is registered in WFCBSubmapSubsystem, and the Event Scripts tab is exposed in the Content Server interface.

You have provided the information necessary to display the Generate Sub-workflow option on the Event Scripts tab in the Content Server interface. Now you must provide the code that the subworkflow() script requires to perform the operation.

Creating event trigger scripts lets the creators of workflows access the Event Scripts tab in the Content Server interface, where they can add custom operations to specific workflow events. This means that the creators of workflows can determine which operation to perform when a specific workflow event occurs in the execution of a workflow.

If you want to restrict access to an event trigger script that you add to Content Server, you can modify the fObjectFactory feature and the FactoryName() script associated with the corresponding event trigger object. Similarly, if you want to specify which Content Server users can attach a performer event trigger script to the Assign Step Performer workflow event, you can modify the fObjectFactory feature and the FactoryName() script contained in the performer event trigger object in your custom module. If you want to specify which Content Server users can attach a submap event trigger script to the Determine Sub-Map To Use workflow event, you can modify the fObjectFactory feature and the FactoryName() script contained in the submap event trigger object.

• fObjectFactory contains a Boolean value. When set to TRUE, this feature works with the FactoryName() script to allow the Admin user (Content Server Administrator) to restrict access to event trigger scripts.
  
  
• FactoryName() returns a string that identifies the event trigger scripts to which you want to restrict access.

To restrict access to event trigger scripts:

1. Locate the event trigger object that contains the event trigger script to which you want to restrict access in your custom module.

2. Set the fObjectFactory feature to TRUE.

3. Type the string value that you want to return in the FactoryName() script.

   This string value is displayed in the Usage Privileges section of the Administer Object and Usage Privileges page.

   Tip:

   Use the name that you specified in the fScriptName  feature by referencing that feature as.fScriptName  in the FactoryName() script.

4. In the modulename Globals object, run the BuildOSpace() script.

5. Save and export your OSpace, and then restart the Livelink Builder.

You can restrict access to general event trigger scripts, performer event trigger scripts, and submap event trigger scripts individually by setting different return values for the FactoryName() scripts for each event trigger object. You can restrict access to all general event trigger scripts, performer event trigger scripts, and submap event trigger scripts together by setting the same return values for the FactoryName() scripts for each event trigger object.

After you modify the fObjectFactory features and the FactoryName() scripts contained in the event trigger objects for the event trigger scripts to which you want to restrict access, you must run the BuildOSpace() script in the Globals object of your custom OSpace. Then, the Admin user can go to the Administer Object and Usage Privileges section of the Content Server Administration page and specify which Content Server users can attach the event trigger scripts to workflow events.

Suppose that you create general, performer, and submap event trigger scripts in your custom module and you want to restrict access to the performer and submap event trigger scripts. You can set the fObjectFactory feature to TRUE and modify the FactoryName() script to return the same string value in the performer and submap event trigger objects. This means that the Admin user can specify which Content Server users can attach the performer and submap event trigger scripts to workflow events. In this case, certain Content Server users can attach the performer and submap event trigger scripts to workflow events and all Content Server users can attach the general event trigger scripts to workflow events.