When an automatic activity is started, it is placed on a queue for execution.
The server facility responsible for executing automatic jobs wakes up at regular intervals and executes the activities in the order in which they appear on the queue. By default, the facility handles all queued activities before going to sleep.
Occasionally, we may encounter a problem with a custom method used in a Workflow Template. We may notice that the custom code associated with the method object is not running. But in many cases, we don't know where to begin to determine where the problem is.
Below is a series of tests that can be run to determine if it's your custom method that is failing or if it's something else on your eContent Server.
1. If your custom method is failing, most likely you will see 'paused' tasks in the Inbox of the user or users following the automatic activity.
This is typically the result of a syntax error in the code of the method. Verify that the method can run outside of the Workflow Template using an Apply API. Or run the method from the Documentum Administrator and test the code.
2 Replace your custom method with the dm_noop_auto method in your Workflow Template and run the Workflow again. If this works, that will indicate there is a problem with your custom method.
3. Turn Trace Launch on the custom method object and run the Workflow again, any errors that are encountered with the method will be displayed in the Server log. Review the server log and the trace launch information, check the method verb used.
4. Consider moving the method content file into the Docbase versus say placing it in the \bin directory on the eContent Server1.
If you do this, make sure, you update your method verb; it will not be necessary to include the '-f' for the file. Only the '-e' Entry Point will be necessary.
5. Check the header of the custom method code. Every method used in a Workflow Template needs the following parameters:
Sample below:
Sub Entry_Point (ByVal stub1 As String, _ ' -docbase
ByVal docbase As String, _
ByVal stub2 As String, _ ' -user
ByVal username As String, _
ByVal stub3 As String, _ ' -packageID
ByVal workitemID As String, _
ByVal stub4 As String, _ ' -ticket
ByVal ticket As String, _
ByVal stub5 As String, _ ' -mode
ByVal mode As String)
It doesn't have to be called 'Entry Point' but it does need to contain parameters listed.
6. Verify that the following APIs are used in the method content code.
- Connect, Acquire, and Complete
If you're uncertain about the syntax of these APIs, refer to the Server Reference Manual.
If one of these APIs is missing in your method code, your custom method will not work.
If you're looking for a code sample, view the method content for the 'dm_noop_auto' method.
This method object contains all of the APIs needed. When using this method object, it connects, acquires and performs a complete.
7. Check your method verb, for misspellings and case sensitivity.
8. Check if the agent exec process is running on the eContent Server. This will determine if the Workflow agent is running as well.
Note: you will not a see a workflow agent process id or process on your server.
9. Check the return value of the automatic method. See example below.
If the custom method exited with zero, server treated it as successful completion.
Therefore, if anything fails within the custom method, the method should exit with non-zero value. Then server knows the completion of the automatic activity failed and server will do something about the automatic workitem accordingly.
e.g. The following is part of the sample script dm_noop_auto_method, if the acquire failed, this script did exit with 10.
status = dmAPIExec("acquire," & sess & "," & packageID)
If status = False Then
Print "The acquire did not succeed"
Print dmAPIGet("getmessage," & sess)
dmExit(10)
End If
10. Are you trying to run this custom method with multiple packages?
There is a known bug on this issue. When attempting to use WF_PromoteLifecycle it fails to promote the optional packages and only promotes the required package. BUG#42500.
11. Setup and configure java.ini file, if Content Server runs on Unix platform.
This is documented in the Server installation guide on how to configure this file correctly.
Documentum provides a sample file called 'java_def.ini'. This file can be copied and modified.
Java.ini file needs to be under $DM_HOME\bin.
12. Update the Java Runtime Environment (JRE).
If using Content Server 5.1, java needs to be at 1.3.1.04 or 1.4.
If using eContent Server 4.2, java needs to be at 1.2.2
No comments:
Post a Comment