I am working with PPM 9.13 and I have some problems when I try to pass a value between requests.
I have a request (REQUEST2) that is created from other request (REQUEST1) with the command "ksc_copy_request". So in this case I can't say that these requests have the relationship "father-son" because the REQUETS2 it is a copy of other request that has already a father so it is inheriting this relation too.
I wonder if it is possible to pass a value or a variable from REQUEST1 to REQUEST2 taking into account the relationship I have explained before.
I am not sure I understand your question, so please clarify.
By passing a value/variable, do you mean field value on the request form?
When you copy a request from another request, all fileds are copied with it by default (except resources).
When using ksc_copy_request there are parameters that can control the copying behaviour.
REQUEST_TYPE_ID (default is the same request type as FROM_REQUEST)
WORKFLOW_ID (NULL by default)
COPY_FIELDS (Y by default)
COPY_NOTES (Y by default)
CREATE_REFERENCE (Y by default)
REF_RELATIONSHIP_ID (when CREATE_REFERECE is set to Y - you can specify the nature of created relationships)
SUBMIT (default Y)
STATUS_NAME (NULL by default)
PROCESS_RULE (Y by default)
So, if request_1 TEST field is RED, and you copy it into request_2. Request_2 will get RED in TEST field too. If request_1 has relationship to another request, when copying the request, you should have the relationships defined too (by default).
There is an additional capability to pass values to the child request when using ksc_copy_request. You can specify parameter mapping with dissimilar tokens and you can create custom values based on more than one token with the VALIDATION_NAME parameter. I think this feature was include in either the 9.12 or 9.14 release. The documentation is probably available in the release notes.
After creation I have modified a field called "INI" in the new request by a PL/SQL function to indicate in which step I want to start the workflow.
I need the new requets starts in a step different than the step implemented as a initial workflow step.
The first step of my new request is an automatic step in which the field "INI" is checked in order to transition to a step or other. If I configured this step as a manually step, that works. If the field is automatic, the transition is executed before the field has saved the correct value.
I have test this creating a query type field and it say me the value of the parameter. And I can test with a token type field. In the last case if the step is automatic the field is null.
How can I do to have the field populated before start the workflow?
Create new Request: ksc_copy_request FROM_REQUEST_ID="[SQL_OUTPUT]" REQUEST_TYPE_ID="[T 90 SIPO_ID]" WORKFLOW_ID="[FLUJO_ID]" COPY_FIELDS="Y" COPY_NOTES="N" CREATE_REFERENCE="N" Save Id New Request: ksc_set NUEVO_ID="[SQL_OUTPUT]" Change Status: ksc_move_request_workflow REQUEST_ID = "[NUEVO_ID]" FROM_WORKFLOW_STEP_SEQ= "1" EVENT_NAME = "FORCE_TRANSITION" RESULT_VISIBLE_VALUE = "REUT_ACEP" TO_WORKFLOW_STEP_SEQ = "10"
We are not sure the values we have to assign to the parameters signed in bols letter: RESULT_VISIBLE_VALUE and EVEN_NAME. Are the others parameters ok???
About the option you suggest we dont knonw how to execute PL/SQL before copy_request if we dont know yet the ID of the new request generated. So, we can't populate the field INI with anyvalue before create the request...
When we want a child request to behave differently from when it is submitted directly, we use the following commands in the child to see if it has a parent:
ksc_run_sql QUERY_STRING="select parameter1 from knta_references_v where source_id = [REQ.REQUEST_ID] and target_type_code = 20" ENV_NAME="KINTANA_SERVER" ksc_store PARENT="[SQL_OUTPUT]"
We then use a token execution step to branch based on whether there is a parent request. This is easily refined to branch for specific parent request types if this is appropriate.
In some cases, we have simplified this to simply have the parent put its request_id into a field that is then inherited by the child. It is much simpler to just pass a value to the child when it is created than to try to manipulate the child's data after it is created.
If you do change the value of a parameter in the child with SQL statements, you will need to clear the request cache in order to get it picked up.
If you use the move workflow special command to control the child's execution, the user_id used to execute the command will need to have security access to the child's FROM step.
We have resolved the issue, including a new field in the parent request and populating it before create the child. In this way, the child will inherit the value at the creation time and this value will be evaluated in an automatic step created as first step in the child's workflow.
Depend on the value of the child's field, the next step will be one or another.