Hi, I have a need to set the source and destination environment values, in one or more workflow steps, on the fly - with commands from an execution step. (This is to make a workflow more flexible when dealing with potentially multiple environments.)
I would like to use KSC_STORE, but as I understand it, that command can only be used for custom fields.
Is there any way to do this for standard fields, like the environment fields? What have you all come up with?
Thanks. However, that implies that I need to change all of the object types, to include the new command. Is that right? I was hoping to be able to leave the object types (particularly the Oracle Apps ones) untouched...
You should be able to use a User Data field to hold this information. Package, Package Line, Workflow or Workflow Step User Data could be used. The choice would depend on how global and how dynamic the value would be. You would also need to decide who or how the value is selected: does the user select a value or is it done with workflow step commands? In the case I mentioned, we are setting the value in a read only field on the request with a rule. Similar functionality could be achieved with workflow step commands after the package is submitted.
That's exactly what we plan to do. We have a 'project' validation that contains all of the environments needed for requests of that 'project'. So, the request would have fields containing the environments needed. (One environment for DEV, one environment for TEST, etc.)
Can you please give me more info about how you are handling this? -Jim
I am a bit confused. You refer to Object Types (Deployment Management) and request fields (Demand Management). Commands are defined by you for a request and can reference any field you want. You indicated you wanted to use OOTB OTs with no modifications, though, which means none of the commands would be adjusted to get values from fields from the OT or the package line.
We build a deployment workflow tailored to each project and configure each workflow step with an environment group listing the environments appropriate for that step. There are individual steps for deploying to development, production, etc. We also use the OOTB OTs as models and modify them to meet our needs. This can lead to additional work when upgrading but it is the most efficient way of getting the product to do what we want.