Forum

The description you see on the CR Object page and elsewhere, is in the configuration of Phire and can easily be changed through the setup pages.  Navigate to the Domain Setup Wizard found at: Phire Architect > Architect Administration > Domain Setup Wizard, Step: 3. Application Codes.  You’ll see a section for the “File Type” configuration, where the available codes and descriptions are setup.  Just change and save; the change will take effect immediately wherever that File Type is referenced.

There are two aspects to consider:  the workflow/CR status and the object versions.  The workflow/CR can easily be canceled by someone with that permission using the button in the upper left of the Task page.  Once canceled it’s still available for historical purposes and could be reopened or physically deleted using the CR Reopen/Delete component (see: Phire Architect > Change Requests > Reopen/Delete CR).

The object versions are something to possibly consider depending on how much work was done within the CR.  If for example the CR had been migrated to TEST, then you might like to “rollback” the migration in TEST so that those changes are undone – you can do that through the “Rollback” button on the Migrations page.  If that button is not available (because no baseline was taken), then you can create a new version set from PROD and ad hoc migrate that back to TEST to restore the original production objects.  Likewise, you might like to restore the original objects to DEVL so that new development could start without any residual changes there.  You can also do that by performing an ad hoc migration back to DEVL using the same baseline version set.  Ultimately, how you handle this will depend on the specific CR, how much work might have been done, and what needs to happen with those objects next.

There is no automated way to skip a workflow step based on existence or non-existence of an object type in the CR – the example being COBOL program which requires the additional manual compile step. The only way to handle your requirement is to make the step to compile the COBOL program an optional step that would be manually skipped by the developer if the CR does not contain a COBOL program. A simple way to communicate and document this situation is for the developer to note the COBOL compile requirement in the migration note.  It is also possible through the workflow API to write a custom method that interrogates the object list and triggers an email or pop-up message as a reminder if there is a COBOL in the list.  Contact support for more information on setting up the workflow API, if that seems like a useful option.

When an Export DMS is executed in Phire, the data file is captured in history, and can be used as the data file on a subsequent Import DMS.   The feature you’re looking for is provided as a button on the script history page.  So starting at the CR Script page, click the “History” hyperlink on the export Data Mover script.  This shows the script execution history where you will see a button like this:  .  Click that button and it will ask you to select the import script to associate with the data (this is a script that you would have written yourself to perform the import as you require).  Once you select the import script, you will see it added to the CR Script page as an Import DMS with the associated data file included.  The import is now ready to be executed either individually or as part of a migration.

If the assignment field on future tasks in the workflow are made display only, then this indicates that the current user does not have permission to reassign tasks.  That permission is granted here:  Phire Architect > Security Administration > Reassign Task Security.  The permission is granted to either a role or an individual user, similar to the other permission sin Phire.  And it can be granted to all task types, or specific task types depending on the requirements being met.

There’s really not an option to limit the effect of the build to specific records out of the migration set in Phire.  The closest thing would be to select to “Build Script” option (instead of “Build Script and Execute”) and let it just generate the script.  Then download it from the build history, edit it to remove unwanted records and execute it manually.

Or, just decline the build options altogether, and build manually after the migration is complete.

Remember also, that the Project Build in Phire is the same operation that you perform using Application Designer.  That feature compares the record definitions to the database object to determine what, if any, change needs to be implemented.  So if a record has not changed – that is, no fields were add/removed/changed – then the record will not be altered during the operation.  To do this, be sure that the build setting “Alter even if no changes” is left unchecked.

The workflow steps are setup on “Page 13: Workflow Definitions” in the Domain Setup Wizard (found at: Phire Architect > Architect Administration > Domain Setup Wizard).  Any changes made on this page will take effect for new Change Requests that are opened, but will not affect existing ones already in progress.  If you wish to apply these workflow changes to existing CRs, then use the “CR Workflow Reset” component found at Phire Architect > Change Requests > CR Workflow Reset.  This component allows you to search for CRs using the domain, CR type and other criteria.  Once the search results are filled, select the CRs to reset and click the “Reset” button.  Follow the prompts to complete the reset.  When doing this, history is preserved and the current status of the CRs is reset based on the selection made.

The “Release” field on the main Change Request page is a prompt against the Release Definitions found at Phire Architect > Change Requests > Release Definition.  Create a new release through this component using the “Add” tab.  The only required fields is the release name and the active/inactive status.  The prompt on the main Change Request page filters out inactive and completed releases.