WHY
I find myself pointing customers who use processes to this option over and over again. It is particularly useful when a CA PPM (Clarity) administrator wants to save on licenses.
Launching a process via a gel script will allow you to change who is running a process on-the-fly to someone else with more permissions. It will also allow you to launch a secondary object-based process to modify an individual object instance using a system action while running a non-object-based process.
For Example, if you want to have a process convert an idea or any other object to a project, most users won’t have sufficient rights to make the necessary changes. You can create one user with sufficient rights to do whatever needs doing and when your user with fewer permissions does something that launches the process, you can simply have a gel script that launces a second process with the user who has sufficient rights to do everything specified as the process owner. When the second process is done, control is returned to the primary process.
Let’s say you are running a non-object-based process as a job and you want to lock/unlock attributes before and after xogging in changes to a number of object instances. Launching a secondary object-based process allows you to lock/unlock your attributes using a System Action instead of updating tables directly which means you are making these changes in a supported way.
I am sure there are many other applications for launching a process via a gel script that I am not mentioning here.
HOW
Use the bpm:startProcess tag (example attached). When you get to the point in your current process where you want to become someone else or make changes to a particular object instance that can’t be done via xog, do it cleanly. Call a GEL script that launches a brand new process as this new super-privileged user or a brand new object-based process for the particular object instance and exit your current one. This way there's no session mess, there's no special table to mess with that might break when the next revision of Clarity comes out and you are never updating tables directly which we all know is a big no-no.
***EXAMPLE:
<gel:script xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:bpm="jelly:com.niku.bpm.gel.BPMTagLibrary"
xmlns:core="jelly:core"
xmlns:gel="jelly:com.niku.union.gel.GELTagLibrary"
xmlns:sql="jelly:sql"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<gel:setDataSource dbId="niku"/>
<!-- Take the target processCode as a parameter -->
<gel:parameter var="processCode"/>
<!-- we will launch this next process on the same object id this script is running on-->
<core:set var="targetObjectId" value="${gel_objectInstanceId}"/>
<!-- we will launch the next process as admin to avoid rights issues -->
<core:set var="targetUserId" value="1"/>
<core:choose>
<!-- Make sure we've supplied the processCode parameter -->
<core:when test="${processCode != null && processCode.length() > 0}">
<sql:query var="results">
SELECT
bdpv.id process_version_id,
bdo.object_name
FROM
bpm_def_processes bdp,
bpm_def_process_versions bdpv,
bpm_def_objects bdo
WHERE bdpv.process_id = bdp.id
and bdo.pk_id = bdpv.id
and bdp.process_code = ?
and (bdo.is_system = 0 or bdo.is_system is null)
<sql:param value="${processCode}"/>
</sql:query>
<!-- Extract the process_version_id, targetObjectKey from the query -->
<core:set var="targetProcessId" value="${results.rows[0].process_version_id}"/>
<core:set var="targetObjectKey" value="${results.rows[0].object_name}"/>
<core:choose>
<!-- start the process if we've got a valid process_version_id -->
<core:when test="${targetProcessId != null}">
<bpm:startProcess processVersionId="${targetProcessId}" initObjectKey="${targetObjectKey}"
initObjectId="${targetObjectId}" initUserId="${targetUserId}"/>
</core:when>
<core:otherwise>
<gel:log level="ERROR">Cannot find process code '${processCode}' to launch. </gel:log>
</core:otherwise>
</core:choose>
</core:when>
<core:otherwise>
<gel:log level="ERROR">processCode parameter has not been supplied</gel:log>
</core:otherwise>
</core:choose>
</gel:script>
*** Gel script written by Sean Harp
NOTE: If you are running a non-object-based process, you won’t be able to use the existing object id like this script is doing. However, you will already have had to determine the object_instance_id in the gel script you have already created. Just use that project id instead of the gel_objectInstanceId. Also, make sure you only launch your process(es) once per object instance so that you don’t get a separate process instance running for each change you make on a single object instance.
TERMINOLOGY
Object-based process: An object has been selected on the Objects tab of the process definition. Each process instance that is launched is designed to work on a single object instance.
Non-Object-based process: No object has been selected on the Objects tab of the process definition. These processes usually make similar changes to many object instances or they xog in data to many object instances. These processes can be launched from the Processes tab in the Organizer. But, they are usually launched via a scheduled job.