Forum

This is done through the workflow setup in the Domain Setup Wizard (found at:  Phire Architect > Architect Administration > Domain Setup Wizard).  Go to Step 14. Workflow Definitions, and drill into the details for the migration step in question.  Change the Task Trigger from “Migration” to “Migration w/Baseline” that forces the selection.

In the templates delivered with Phire this option is used for the production migration, and the regular “Migration” is used for the lower environments.  Often, in test environments customers don’t really rollback changes (if there’s a problem found in testing they just fail it in the workflow and re-migration after the developer has fixed it).  But it is important to ensure that the baseline is done migrating to production.

Also, note that this aspect of the workflow is set in the CR at the time it’s created and the setup will only affect new CRs moving forward.  The CR Workflow Reset component is available to address existing CRs if necessary.

Looking at the workflow setup, the step named “Create Migration Set” is typically set with a source database and thus only gets marked complete when the developer successfully creates a Migration Set from that particular source database.  So you can be sure that the workflow will not advance to the later migration steps without that requirement being met.

Next, the migration steps themselves have an optional source in the setup, which locks it into migrating only from a Migration Set created from a particular source.  The source database value is often left blank allowing more flexibility, but can be entered to provide this tighter control.

The “Directory Import” function is meant to be a feature for the developer to facilitate the inputting of the CR object list. Security implications of this feature is minimal since the files are not being imported; instead, this feature is simply determining the list of the files in a directory that is accessible from the Phire application server to make it easier to add the file names to the CR without having to type each file name.

Since this is a development function, there is usually not a requirement to disable this feature.  So, if you want to completely disable this function, you can do so by updating the PHI_CR_FILE_ADD page and making the “Directory Import” button invisible.

This information is captured in the history as the objects are processed, and is visible on-line in the View Version Set page.  From the CR Objects page, use the View Version Sets button to see all of the Version Sets created for the CR, then click the “History” hyperlink for the set of interest.  At that point, you will see each object that was processed with a success column and a result message.  You can easily isolate the error, including the objects not found, by selecting the “Show Errors Only” checkbox at the top.

There is an option available to delete version sets, found at:  Phire Architect > Architect Administration > Purge Object Versions.  This administrative component allows you to search for and delete version sets using a variety of criteria.  This component was intended to be used only by administrators, so there is no direct access to it from the CR component.  The permission to use this component is controlled by the normal PeopleTools role/permission list access to the component.

When you initiate the Rollback feature in Phire, objects that do not exist in the target at the time the baseline version is taken will be automatically deleted. The driver for the action Phire takes during a rollback (either copy or delete) depends on the state of the object in the target when the baseline backup is made.  If the object exists when the baseline is taken, then the action for the rollback is set to COPY. If the object does not exist when the baseline is taken, then the action for the rollback is set to DELETE.

You can view the action Phire will perform for each object when the rollback is initiated by looking at the baseline Version Set. From the CR, navigate to the “Objects” tab and click on the “View Version Set” icon below the CR Number. Click on the “Objects” link next to the Baseline backup from <TARGET>. For each object, the Action to be taken for the restore will be displayed.

One possible cause for the restore action to not be set to DELETE is if you perform multiple migrations to the same database. The rollback of the last migration will not result in the “new” objects to be deleted since those objects may not have existed when the first migration was done, however, they do exist when the last migration is performed. In this scenario, you can Restore the baseline backup taken prior to the first migration to delete the objects.

You can delete a workflow by deleting the CR Type which it is based on.  That is, navigate to Step 3. Application Codes of the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard), open the section for the Change Request Type, and delete the row.  That will also remove the setup on Step 13 and 14 associated with that type.

A workflow in Phire is derived from the Change Request Type definition.  So you would first create a new CR Type, and then you can create the task list that’s associated.

So start by navigating to:  Phire Architect > Architect Administration > Domain Setup Wizard, Step 3. Application Codes.  In the section for Change Request Types, you can create a new type with a description.  Then on Step 13. Workflow Definitions, you can create the series of tasks that make up the workflow.  Alternatively, if you have an existing workflow that’s pretty close to the one you’re trying to create, you can use the Copy Workflow button after you’ve create the new CR Type value.  Also, complete the setup on Step 14. Workflow Databases for the new workflow.  At that point it should be ready to test and begin using the new workflow.

We deliver a role that is designed to provide a read-only view for users, which is named PHI_CR_READONLY_ROLE.  Remember to setup Domain Security for the role within Phire so it can access the domain and search for Change Requests.  The only permission the role needs is “Open Existing CR” to open CRs in that domain and look around.

We provide the ability to copy the workflow setup from one domain to another using a Data Mover script. You will find a DMS named “COPY_WORKFLOW.DMS” in the scripts folder in the Phire release package. Prior to running this script, you will need to replace the tag values that are in brackets. Also, after the workflow is copied over, be sure to define domain security for the new CR Type.