This isn't too hard actually. As long as whatever document you are attaching meets the package criteria, you shouldn't have a problem. By that I mean, make sure that if you are adding an object of type dm_document, the package isn't looking for dm_xyz_custom_type.
If you already have a running workflow, you'll need to know the associated package or packages.
Note: It's confusing, but the IDfWorkflow.addAttachment method is not what you're looking for. Documents are routed through packages (IDfPackage).
You didn't mention how you needed to add a document to a workflow; either manually or through a workflow activity. I'll try and cover the bases. First, the easiest way is to add a document to a running workflow is find whoever has a pending workitem, open that task through their Documentum inbox and click the 'Add attachment' button. Problem solved. Ah, but it's never that easy. If you needed to manually slip in a document into a package, you can use a little DQL to find the most recent package for your workflow (providing you have the workflow_id):
SELECT r_object_id from dmi_package where r_workflow_id = '4d_yaddayadda'
Then a quick little API insert command setting the r_component_id to the r_object_id of the document you wish to insert (along with the other attributes you need) will also do the trick. However, you asked for a DFC method! Ah, you're in luck. I'm going to assume that you want to do this in a workflow activity of some such. That's good because it's easy to do so if you already have the workitem object. Here's some quick psuedocode that shows how to get a workflow package and insert the document you need. (I'm still rusty from the holidays so my code is going to be horrible.)
IDfWorkitem wi = (IDfWorkitem)sess.getObject(tasks.getId("item_id"));
IDfActivity act = wi.getActivity();
for (int i = 0; i < act.getPackageCount(); i++) // If you have more than one package
{
IDfId packageId = act.getPackageId(i);
IDfPackage packageObj = wi.getPackage(packageId);
String packageName = packageObj.getPackageName();
if (packageName.equals "Package0")
packageObj.appendId(r_component_id, object_id value of document being added to package)
packageObj.appendId(r_component_chron_id, object_id value of document being added to package)
packageObj.appendString(r_component_name, name of document being added to package)
packageObj.appendString(r_package_label, CURRENT)
}
That'll should do the trick. You don't want to use wi.addPackage because that would add an additional package to the workflow and you don't really want that if you can avoid it. That can cause all sorts of issues later on in the workflow. Hope this helps.
Wednesday, June 10, 2009
What happens if automatic activity fails, and what should I do to get out of it
Solution and Explanation:
If workflow is initiated, workflow instance is created and set to state running state. As the workflow progresses, the runtime activity information is updated in dm_workflow object and workitem objects corresponding to the runtime activity staus are created.
After workflow is successfully completed, the workflow object and workitem objects are removed from Docbase.
If a method fails for a automatic activity, then workflow stays active state, but runtime activity goes to terminated state and workitem goes to Apaused.
You can restart the failed activity, with restart API. Resume API does not work in this case, since workflow and activity were not halted. SN 14292 is helpful to call restart.
State information for workflow, runtime activity are kept in dm_workflow object, and that for woritem are kept in workitem object.
<< workflow >>
r_runtime_state : current state of the workflow.
0, meaing dormant
1, meaning running
2, meaning finished
3, meaning halted
4, meaning terminated
r_act_name (R) : activity identifier as defined in dm_process object
r_act_state (R) : activity's current status
0, meaing dormant
1, meaning active
2, meaning finished
3, meaning halted
4, meaning terminated
<< work item >>
r_runtime_state
0, meaning dormant
1, meaning acquired
2, meaning finished
3, meaning paused
4, meaning Dpaused (a work item in the dormant state is paused)
5, meaning Apaused (a work item in the acquired state is paused)
6, meaning Ppaused (a work item in the paused state is paused)
Values 4-6 occur when a workflow containing the work item is halted.
If workflow is initiated, workflow instance is created and set to state running state. As the workflow progresses, the runtime activity information is updated in dm_workflow object and workitem objects corresponding to the runtime activity staus are created.
After workflow is successfully completed, the workflow object and workitem objects are removed from Docbase.
If a method fails for a automatic activity, then workflow stays active state, but runtime activity goes to terminated state and workitem goes to Apaused.
You can restart the failed activity, with restart API. Resume API does not work in this case, since workflow and activity were not halted. SN 14292 is helpful to call restart.
State information for workflow, runtime activity are kept in dm_workflow object, and that for woritem are kept in workitem object.
<< workflow >>
r_runtime_state : current state of the workflow.
0, meaing dormant
1, meaning running
2, meaning finished
3, meaning halted
4, meaning terminated
r_act_name (R) : activity identifier as defined in dm_process object
r_act_state (R) : activity's current status
0, meaing dormant
1, meaning active
2, meaning finished
3, meaning halted
4, meaning terminated
<< work item >>
r_runtime_state
0, meaning dormant
1, meaning acquired
2, meaning finished
3, meaning paused
4, meaning Dpaused (a work item in the dormant state is paused)
5, meaning Apaused (a work item in the acquired state is paused)
6, meaning Ppaused (a work item in the paused state is paused)
Values 4-6 occur when a workflow containing the work item is halted.
Why are my automatic activities failing when using my custom methods on ContentServer
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
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
Code sample to run workflow with API
Symptom: how to create and handle workflow instance, when a workflow
template (process) is defined by graphical Workflow Manager in
Desktop Client.
Solution:
1. Create Workflow definition (dm_process) with Desktop.
Initiate --> AutoFirst --> ManualSecond --> End
AutoFirst : Automatic Activity run with dm_noop_auto_method.
ManualSecond : Manual Activity run by a single user.
Package from Initiate to AutoFirst, optional package Package0
is defined.Package from AutoFirst to ManualSecond, optional
package Package0 is defined.
So this workflow can be started with no package added. If the
package is set to CURRENT, then this workflow can be started
only with attached package.
2. Get r_object_id of this Workflow definition (Process)
DQL> select r_object_id, object_name from dm_process
3. Create a workflow instance
API> create,c,dm_workflow
4d00800080000911
API> set,c,l,process_id
SET> 4b0080008000392a
OK
API> set,c,l,object_name
SET> mySimpleWF
OK
API> save,c,l
OK
You can see a Workflow instance is created.
DQL> select * from dm_workflow
r_object_id object_name process_id
------------------- --------------- -------------------
4d00800080000911 mySimpleWF 4b0080008000392a
4. Start the workflow
API> execute,c,4d00800080000911
But there is no dmi_workitem or dmi_package.
DQL> select r_object_id, r_act_seqno, r_runtime_state from dmi_workitem
r_object_id r_act_seqno r_runtime_state
---------------- ---------------------- ----------------------
(0 rows affected)
DQL> select r_object_id, r_workflow_id, r_package_name from dmi_package
r_object_id r_workflow_id r_package_name
--------------- ---------------- ----------------
(0 rows affected)
5. Add package to the first activity of workflow
API> addpackage,c,4d00800080000911,AutoFirst,Input:0,Package0,dm_sysobject,,,090080008000193f
...
4900800080000924
Where
AutoFirst : Activity name in Workflow instance
Input:0 : Input port name for the first activity
Package0 : Package name
090080008000193f : r_object_id of document object which shall be delivered to next activity.
4900800080000924 is the r_object_id of the dmi_package object, just created. And dmi_workitem and dmi_package objects are created, according to the workflow definition.
I watched that dmi_workitem objects are created only after all the dmi_package objects are attached for the first activity.
DQL> select r_object_id, r_act_seqno, r_runtime_state, r_auto_method_id from dmi_workitem
r_object_id r_act_seqno r_runtime_state r_auto_method_id
---------------- ---------------------- ---------------------- ----------------
4a0080008000091f 1 0 0000000000000000
4a0080008000091e 0 2 1000800080003528
DQL> select r_object_id, r_workflow_id, r_package_name from dmi_package
r_object_id r_workflow_id r_package_name
---------------- ---------------- ----------------
4900800080000925 4d00800080000911 Package0
4900800080000924 4d00800080000911 Package0
The package name should be defined in workflow definition, otherwise
addpackage API fails.
API> addpackage,c,l,AutoFirst,Input:0,Package1,dm_sysobject,,,090080008000193f
[DM_WORKFLOW_E_INVALID_PACKAGE_INPUT_PORT]error: "The package, Package1, is not in the specified input port, Input:0."
6. Acquire the workitem for corresponding to the second activity of the workflow
API> acquire,c,4a0080008000091f
DQL> select r_object_id, r_act_seqno, r_runtime_state, r_auto_method_id from dmi_workitem
r_object_id r_act_seqno r_runtime_state r_auto_method_id
---------------- ---------------------- ---------------------- ----------------
4a0080008000091f 1 1 0000000000000000
4a0080008000091e 0 2 1000800080003528
7. Acquire the workitem for corresponding to the second activity of the workflow
API> complete,c,4a0080008000091f
...
OK
Then the workflow, workitem and package objects are removed, since this is the next activity is End activity.
DQL> select * from dm_workflow
r_object_id object_name process_id
------------------- --------------- -------------------
(0 rows affected)
DQL> select r_object_id, r_act_seqno, r_runtime_state from dmi_workitem
r_object_id r_act_seqno r_runtime_state
--------------- ---------------------- ----------------------
(0 rows affected)
DQL> select r_object_id, r_workflow_id, r_package_name from dmi_package
r_object_id r_workflow_id r_package_name
---------------- ---------------- ----------------
(0 rows affected)
template (process) is defined by graphical Workflow Manager in
Desktop Client.
Solution:
1. Create Workflow definition (dm_process) with Desktop.
Initiate --> AutoFirst --> ManualSecond --> End
AutoFirst : Automatic Activity run with dm_noop_auto_method.
ManualSecond : Manual Activity run by a single user.
Package from Initiate to AutoFirst, optional package Package0
is defined.Package from AutoFirst to ManualSecond, optional
package Package0 is defined.
So this workflow can be started with no package added. If the
package is set to CURRENT, then this workflow can be started
only with attached package.
2. Get r_object_id of this Workflow definition (Process)
DQL> select r_object_id, object_name from dm_process
3. Create a workflow instance
API> create,c,dm_workflow
4d00800080000911
API> set,c,l,process_id
SET> 4b0080008000392a
OK
API> set,c,l,object_name
SET> mySimpleWF
OK
API> save,c,l
OK
You can see a Workflow instance is created.
DQL> select * from dm_workflow
r_object_id object_name process_id
------------------- --------------- -------------------
4d00800080000911 mySimpleWF 4b0080008000392a
4. Start the workflow
API> execute,c,4d00800080000911
But there is no dmi_workitem or dmi_package.
DQL> select r_object_id, r_act_seqno, r_runtime_state from dmi_workitem
r_object_id r_act_seqno r_runtime_state
---------------- ---------------------- ----------------------
(0 rows affected)
DQL> select r_object_id, r_workflow_id, r_package_name from dmi_package
r_object_id r_workflow_id r_package_name
--------------- ---------------- ----------------
(0 rows affected)
5. Add package to the first activity of workflow
API> addpackage,c,4d00800080000911,AutoFirst,Input:0,Package0,dm_sysobject,,,090080008000193f
...
4900800080000924
Where
AutoFirst : Activity name in Workflow instance
Input:0 : Input port name for the first activity
Package0 : Package name
090080008000193f : r_object_id of document object which shall be delivered to next activity.
4900800080000924 is the r_object_id of the dmi_package object, just created. And dmi_workitem and dmi_package objects are created, according to the workflow definition.
I watched that dmi_workitem objects are created only after all the dmi_package objects are attached for the first activity.
DQL> select r_object_id, r_act_seqno, r_runtime_state, r_auto_method_id from dmi_workitem
r_object_id r_act_seqno r_runtime_state r_auto_method_id
---------------- ---------------------- ---------------------- ----------------
4a0080008000091f 1 0 0000000000000000
4a0080008000091e 0 2 1000800080003528
DQL> select r_object_id, r_workflow_id, r_package_name from dmi_package
r_object_id r_workflow_id r_package_name
---------------- ---------------- ----------------
4900800080000925 4d00800080000911 Package0
4900800080000924 4d00800080000911 Package0
The package name should be defined in workflow definition, otherwise
addpackage API fails.
API> addpackage,c,l,AutoFirst,Input:0,Package1,dm_sysobject,,,090080008000193f
[DM_WORKFLOW_E_INVALID_PACKAGE_INPUT_PORT]error: "The package, Package1, is not in the specified input port, Input:0."
6. Acquire the workitem for corresponding to the second activity of the workflow
API> acquire,c,4a0080008000091f
DQL> select r_object_id, r_act_seqno, r_runtime_state, r_auto_method_id from dmi_workitem
r_object_id r_act_seqno r_runtime_state r_auto_method_id
---------------- ---------------------- ---------------------- ----------------
4a0080008000091f 1 1 0000000000000000
4a0080008000091e 0 2 1000800080003528
7. Acquire the workitem for corresponding to the second activity of the workflow
API> complete,c,4a0080008000091f
...
OK
Then the workflow, workitem and package objects are removed, since this is the next activity is End activity.
DQL> select * from dm_workflow
r_object_id object_name process_id
------------------- --------------- -------------------
(0 rows affected)
DQL> select r_object_id, r_act_seqno, r_runtime_state from dmi_workitem
r_object_id r_act_seqno r_runtime_state
--------------- ---------------------- ----------------------
(0 rows affected)
DQL> select r_object_id, r_workflow_id, r_package_name from dmi_package
r_object_id r_workflow_id r_package_name
---------------- ---------------- ----------------
(0 rows affected)
Thursday, June 4, 2009
Workflow problems and resolutions
How to pause and resume a workflow?
A workflow is suspended and you would like to resume it.
The workflow was suspended because an activity failed.
Resolution 1
Please note that unfortunately, if you are not able to resume your workflows you will have to restart them.
Pausing and resuming work items
You can pause a dormant work item. Work items are dormant until they are acquired or a user delegates the work item. You cannot pause an acquired work item.
To pause a dormant work item, you must be the workflow supervisor or a user with Sysadmin or Superuser privileges. Use a Pause method to pause a work item.
Resuming a paused work item returns the work item to the dormant state. To resume a paused work item, you must be the workflow supervisor or a user with Sysadmin or Superuser privileges. Use a Resume method.
Syntax
To pause:
dmAPIExec("pause,c,workitem_id")
To resume halted workflow, halted activity, or paused work item:
dmAPIExec("resume,c,object_id")
workitem_id: specifies the work item that you want to pause.
object_id: identifies the paused workflow, activity, work item, or SysObject to resume. Use the object's object ID.
Restarting a halted ow or failed activity
Restarting a workflow removes all generated work items and packages and restarts the workflow from the beginning, with all activity instances set to dormant.
Restarting a failed activity sets the activity's state to Active.
To restart a halted workflow or failed activity, use a Restart method.
Syntax
dmAPIExec("restart,c,workflow_id")
Resolution 2
For a specific workflow, get the paused tasks by running the DQL :
select r.r_act_seqno, wf.r_object_id as workflow_id
from dmi_workitem r, dm_workflow wf, dm_activity act
where wf.r_object_id = r.r_workflow_id
and r.r_act_def_id = act.r_object_id
and r_runtime_state = 5 and wf.object_name=""
The above DQL gives u the activity sequence number and workflow id.
Then use IAPI to restart the paused task using :
restart,c,,sequence_no.
Please note: Attribute values for r_runtime_state of dmi_workitem between 4 & 6 occurs when a
workflow containing the work item is halted. So you need to restart the workflow, user restart API method to do this.
select r_object_id,r_runtime_state from dmi_workitem
r_runtime_state indicates the current state of
the workflow. Values are:
Contains the current state of the work item.
Valid value are:
0, meaning dormant 1, meaning acquired
2, meaning finished 3, meaning paused
4, meaning Dpaused (a work item in the dormant state is paused)
5, meaning Apaused (a work item in theacquired state is paused)
6, meaning Ppaused (a work item in the paused state is paused)
Values 4-6 occur when a workflow containing the work item is halted.
Is it possible to restart TERMINATED workflows?
A dm_workflow object is an instance of the dm_process Object
(The WF Template) and is used to represent an active WF. When the WF is
Terminated, these are automatically removed from the system. You can never
create, save them. These are handled primarily by the CS
I need DQL query to find all attachments names/ids from
all started workflows:
The following dql returns all the attachments
SELECT r_component_id, r_component_name
FROM dmi_wf_attachment
WHERE r_workflow_id IN(select r_object_id from dm_workflow)
The following dql returns all the packages
SELECT DISTINCT r_component_id, r_component_name
FROM dmi_package
WHERE r_workflow_id IN(select r_object_id from dm_workflow)
DQL to find no. of attachments + their names in all started workflows
the key is dmi_wf_attachment
Query to retrieve objects attached to workflows
select so.r_object_id,so.r_object_type,so.object_name,wf.object_name as wfname, wf.r_runtime_state
from dm_sysobject (ALL) so, dmi_wf_attachment wfa,dm_workflow wf
where wfa.r_component_id = so.r_object_id
and wfa.r_workflow_id = wf.r_object_id
Add any additional where clause as r_runtime_state = 1 as you please
Query to retrieve workflows with more than 1 attachment
select wf.r_object_id,wf.object_name,wf.r_runtime_state,count(wfa.r_component_id) as noofattachments
from dm_workflow wf,dmi_wf_attachment wfa
where wfa.r_workflow_id = wf.r_object_id
group by wf.r_object_id,wf.object_name,wf.r_runtime_state
having count(wfa.r_component_id) > 1
Again, add any additional where clause if required
SELECT distinct a.r_workflow_id, c.r_component_id as doc_object_id, c.r_component_name as document_name, b.object_name as activity_name
FROM dmi_workitem a, dm_activity b, dmi_package_r c, dmi_package_s d
WHERE d.r_workflow_id = a.r_workflow_id
AND c.r_object_id = d.r_object_id
AND a.r_act_def_id = b.r_object_id
ORDER BY a.r_workflow_id;
Output will be:-
r_workflow_id doc_object_id document_name activity_name
A workflow is suspended and you would like to resume it.
The workflow was suspended because an activity failed.
Resolution 1
Please note that unfortunately, if you are not able to resume your workflows you will have to restart them.
Pausing and resuming work items
You can pause a dormant work item. Work items are dormant until they are acquired or a user delegates the work item. You cannot pause an acquired work item.
To pause a dormant work item, you must be the workflow supervisor or a user with Sysadmin or Superuser privileges. Use a Pause method to pause a work item.
Resuming a paused work item returns the work item to the dormant state. To resume a paused work item, you must be the workflow supervisor or a user with Sysadmin or Superuser privileges. Use a Resume method.
Syntax
To pause:
dmAPIExec("pause,c,workitem_id")
To resume halted workflow, halted activity, or paused work item:
dmAPIExec("resume,c,object_id")
workitem_id: specifies the work item that you want to pause.
object_id: identifies the paused workflow, activity, work item, or SysObject to resume. Use the object's object ID.
Restarting a halted ow or failed activity
Restarting a workflow removes all generated work items and packages and restarts the workflow from the beginning, with all activity instances set to dormant.
Restarting a failed activity sets the activity's state to Active.
To restart a halted workflow or failed activity, use a Restart method.
Syntax
dmAPIExec("restart,c,workflow_id")
Resolution 2
For a specific workflow, get the paused tasks by running the DQL :
select r.r_act_seqno, wf.r_object_id as workflow_id
from dmi_workitem r, dm_workflow wf, dm_activity act
where wf.r_object_id = r.r_workflow_id
and r.r_act_def_id = act.r_object_id
and r_runtime_state = 5 and wf.object_name="
The above DQL gives u the activity sequence number and workflow id.
Then use IAPI to restart the paused task using :
restart,c,
Please note: Attribute values for r_runtime_state of dmi_workitem between 4 & 6 occurs when a
workflow containing the work item is halted. So you need to restart the workflow, user restart API method to do this.
select r_object_id,r_runtime_state from dmi_workitem
r_runtime_state indicates the current state of
the workflow. Values are:
Contains the current state of the work item.
Valid value are:
0, meaning dormant 1, meaning acquired
2, meaning finished 3, meaning paused
4, meaning Dpaused (a work item in the dormant state is paused)
5, meaning Apaused (a work item in theacquired state is paused)
6, meaning Ppaused (a work item in the paused state is paused)
Values 4-6 occur when a workflow containing the work item is halted.
Is it possible to restart TERMINATED workflows?
A dm_workflow object is an instance of the dm_process Object
(The WF Template) and is used to represent an active WF. When the WF is
Terminated, these are automatically removed from the system. You can never
create, save them. These are handled primarily by the CS
I need DQL query to find all attachments names/ids from
all started workflows:
The following dql returns all the attachments
SELECT r_component_id, r_component_name
FROM dmi_wf_attachment
WHERE r_workflow_id IN(select r_object_id from dm_workflow)
The following dql returns all the packages
SELECT DISTINCT r_component_id, r_component_name
FROM dmi_package
WHERE r_workflow_id IN(select r_object_id from dm_workflow)
DQL to find no. of attachments + their names in all started workflows
the key is dmi_wf_attachment
Query to retrieve objects attached to workflows
select so.r_object_id,so.r_object_type,so.object_name,wf.object_name as wfname, wf.r_runtime_state
from dm_sysobject (ALL) so, dmi_wf_attachment wfa,dm_workflow wf
where wfa.r_component_id = so.r_object_id
and wfa.r_workflow_id = wf.r_object_id
Add any additional where clause as r_runtime_state = 1 as you please
Query to retrieve workflows with more than 1 attachment
select wf.r_object_id,wf.object_name,wf.r_runtime_state,count(wfa.r_component_id) as noofattachments
from dm_workflow wf,dmi_wf_attachment wfa
where wfa.r_workflow_id = wf.r_object_id
group by wf.r_object_id,wf.object_name,wf.r_runtime_state
having count(wfa.r_component_id) > 1
Again, add any additional where clause if required
SELECT distinct a.r_workflow_id, c.r_component_id as doc_object_id, c.r_component_name as document_name, b.object_name as activity_name
FROM dmi_workitem a, dm_activity b, dmi_package_r c, dmi_package_s d
WHERE d.r_workflow_id = a.r_workflow_id
AND c.r_object_id = d.r_object_id
AND a.r_act_def_id = b.r_object_id
ORDER BY a.r_workflow_id;
Output will be:-
r_workflow_id doc_object_id document_name activity_name
Wednesday, May 27, 2009
How to assign ACL to a Workflow?
Here is what you do.
1) Get the r_object_id of the workflow definition
select r_object_id from dm_process where object_name = 'name of your workflow definition';
2) use update statement to update the ACL.
update dm_process object set acl_name = 'acl you created' where r_object_id = ' from earlier query';
second way:--
One way is to login to DA and update it from there. You need to find out where the process template is store though. Get the i_folder_id of the dm_process object and then r_folder_path of dm_folder.
Login to DA and go to the specified folder path. In DA change the filter to "show all object" and find the workflow definition. Go to properties and you can assign the acl from there.
If this answers your question please mark it as answered and award points.
1) Get the r_object_id of the workflow definition
select r_object_id from dm_process where object_name = 'name of your workflow definition';
2) use update statement to update the ACL.
update dm_process object set acl_name = 'acl you created' where r_object_id = ' from earlier query';
second way:--
One way is to login to DA and update it from there. You need to find out where the process template is store though. Get the i_folder_id of the dm_process object and then r_folder_path of dm_folder.
Login to DA and go to the specified folder path. In DA change the filter to "show all object" and find the workflow definition. Go to properties and you can assign the acl from there.
If this answers your question please mark it as answered and award points.
Friday, April 10, 2009
How to see completed workflows?
In order to view completed workflows, you need to enable workflow auditing. Workflow Manager has an option to turn auditing ON within a workflow template to view completed workflows.
From Workflow Manager:
1) Uninstall template
2) File > Template Properties
3) Under Template Audit Trail Setting, select option ‘Always On’ - Audit trail data for each instance will be available and saved at workflow completions.
DCTM 5.3SP1 dmclean has a new argument -clean_aborted_wf. If specified, the method removes all aborted workflows in the repository. You can set this using DA
OR
Symptoms
Completed activities will be automatically removed from inbox. So where to find the information about completed workflows?
Cause
Workflows can be reviewed after they are completed only if you enable the audit trail.
If the audit trail is enabled, we can simply check completed workflows on workflow reporting page.
Resolution
1. Steps to enable the audit trail for workflow:
* If use Process Manager: File -> Template Properties -> Template Audit Trail Setting -> Yes
* If use Process Builder: Tools -> Process Properties -> Audit Trail Setting -> Yes
2. Steps to show the workflow reporting page:
Tools -> Workflow -> Workflow Reporting -> From drop-down list on the up-right corner of the page, select Completed Workflows
From Workflow Manager:
1) Uninstall template
2) File > Template Properties
3) Under Template Audit Trail Setting, select option ‘Always On’ - Audit trail data for each instance will be available and saved at workflow completions.
DCTM 5.3SP1 dmclean has a new argument -clean_aborted_wf. If specified, the method removes all aborted workflows in the repository. You can set this using DA
OR
Symptoms
Completed activities will be automatically removed from inbox. So where to find the information about completed workflows?
Cause
Workflows can be reviewed after they are completed only if you enable the audit trail.
If the audit trail is enabled, we can simply check completed workflows on workflow reporting page.
Resolution
1. Steps to enable the audit trail for workflow:
* If use Process Manager: File -> Template Properties -> Template Audit Trail Setting -> Yes
* If use Process Builder: Tools -> Process Properties -> Audit Trail Setting -> Yes
2. Steps to show the workflow reporting page:
Tools -> Workflow -> Workflow Reporting -> From drop-down list on the up-right corner of the page, select Completed Workflows
Subscribe to:
Posts (Atom)