Project and Portfolio Management Practitioners Forum
cancel

Picking up the correct source environment for package line migration fields

Highlighted
Linda Hauck
Respected Contributor.

Picking up the correct source environment for package line migration fields

I have created an Oracle package migration workflow that uses logic based on selection from User Data on the package, to pickup the correct source environment. This works fine while executing the package itself. The problem is, when setting up the package line itself, say for instance for an AOL function, the correct data source environment is not accessed. The list of functions that come up to choose from just happens to be what the first hard-coded source environment is in the package workflow.
How can I access the workflow engine at this point? There really is no saved package line yet.
4 REPLIES
Jim Esler
Acclaimed Contributor.

Re: Picking up the correct source environment for package line migration fields

We redirect object type field validations to an environment not specified in the workflow with a command like the following in the validation command list:

ksc_connect_source_server SOURCE_ENV="[WF.VUD.PROJECT]_MASTER"

You should be able to do something similar with a token referencing the package user data field. I have not tried it, but it appears values set in package user data fields could be accessable after the package is Saved but not yet submitted. It would take some user training to get users to follow a process like that but it may meet your needs.
frank chiang
Valued Contributor.

Re: Picking up the correct source environment for package line migration fields

Linda,

You can definitely override the source environment using a drop-down from the package or package line user data. But that will defeat the purpose of a repeatable process (and makes it harder to be audit) because this means anyone can change the environment in the user data anytime during the deployment process. Also, another draw back is that you might need to modify all the AOL object types and custom object types that will leverage this functionality.
Jason Nichols K
Acclaimed Contributor.

Re: Picking up the correct source environment for package line migration fields

Linda,

I have done something similar many years ago (on version 4.5) where there was a need to be able to move code around between different instances. I had two fields on the form that allowed for the selection of the source and destination environment. To get the workflow to work proper, though, I had to create what I called a spider web workflow. The first step was a token router based on the source env that branched out to token routers for each of the possible source environments. Those routers then branched based on the possible targets that were permissible for that source, e.g. Dev could not migrate directly to Production, but Production could migrate to Dev. The actual "mirgation" workflow was then a sub-workflow and each node had the proper source/destinations set on the sub-workflow and all of the steps inside the sub-workflow were left blank so they would take the top-level assignments. I hope this helps.

Jason
Linda Hauck
Respected Contributor.

Re: Picking up the correct source environment for package line migration fields

Thanks Jim, Frank and Jason for your replies. Filling a package user data token from a list of our DB links works quite well for this, but we are not sure we want to go this route due to the time and upkeep involved in customizing every single AOL object. (To have them use the new validation.)
Might just keep using different package workflows. Just thought having one may help shorten dev time in our effort to go totally "hands-off" with our Oracle migrations.