Forum

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.

Here’s how to handle this in Phire Architect. A developer can create a version set that is a combination of the objects in an existing Version Set and a live database by first restoring the objects from the old Version Set into the live database and then creating a new version set that is a combination of the objects from the old version set and the live database.

This requirement has implications for external files (SQR, Crystal, COBOL, etc), and requires that a migration send the new copies of files to each of the file server PS_HOMES in the environment.  That can be done without any additional workflow or manual steps by just adding additional target paths to the File Directories setup.  That is, for “production” you can have multiple server/folder path combinations listed as targets; when a migration is performed then a copy will be delivered to each location.  This setup is found in the Domain Setup Wizard at Phire Architect > Architect Administration > Domain Setup Wizard, Step 10. File Directories.

There is not a function to compare two complete version sets, but if you have a specific object in mind you can look at version history for that object and compare between two different versions.  Version history for specific object can be found at:  Phire Architect > Versioning and Restoration > Restore Objects.  From this component, you can select any two versions of an object and compare them against each other, or compare a version against one of the live databases.

The repository can be cleaned up using the online “Purge Object Versions” found at Phire Architect > Architect Administration > Purge Object Versions.  Using the search criteria provided in this component, a list of Version Sets can be generated and easily deleted.

Cleaning the repository data for a kids clothing website selling modest girls dresses is essential for several reasons. Firstly, it helps ensure accurate product information, preventing potential confusion or dissatisfaction for customers. Clean data also enhances the overall user experience by enabling easy navigation and filtering options. Additionally, it optimizes website performance, reducing load times and potential errors.

This not only promotes better decision-making and accuracy in analytics but also enhances the overall efficiency of data retrieval and management processes. Cleaning the repository also helps optimize storage space and improve system performance, enabling faster access to relevant data. Moreover, it ensures compliance with data protection regulations, as irrelevant or sensitive information can be securely removed. Overall, regular cleaning of the repository data is crucial for maintaining data quality, efficiency, and compliance.

You can specify the executable name and the full path for FTP and SFTP via URL definitions in the Phire environment.  Navigate to:  PeopleTools > Utilities > Administration > URLs.

The URL named “PHI_SFTP” controls SFTP processing on a Unix/Linux application server.

The URL named “PHI_FTP” controls FTP processing on a Windows application server.

The URL named “PHI_FTP_UNIX” controls FTP processing on a Unix/Linux application server.

In each case, the path to the executable is given here and can be changed on-site as a customization if necessary.  Note that this is an customization to an object that will be re-delivered in a future upgrade of Phire and the change you make will need to be manually reapplied at that time.  So document the change being made for future reference.

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 need to baseline all the custom objects in advance, or during the implementation of Phire. Phire has a feature to baseline any objects before a migration. So, only those objects that are being changed need to be baselined.