Does any current version of Phire have the ability to check-in and check-out code or code sets from the developers (on a daily basis) which could be monitored and controlled by CM personnel in the different test environments?
This question focuses on how Phire gains access to the databases that are the sources/targets for object versioning, migration, compare and so forth. In the original development of Phire, the only option was what we generically call “database links”. This mechanism is database platform-specific and allows the application to communicate through its database directly with the others. In the case of Oracle databases for example, a database link object is created in the Phire database for each of the source/target databases, which the application then uses for direct access. Some years ago, we developed the “JDBC” connectivity as an alternative. In this mechanism, Phire makes connections through integrated java classes that connect to each database using the JDBC protocols.
The overall functionality is identical regardless of the choice, the difference is in the underlying mechanism. And if necessary, each database can be configured differently, although this option would rarely be necessary. So which is right for your installation? The choice centers around three points: performance, security and setup/maintenance.
Performance. For years, we recommended that Microsoft SQL Server and DB2 customers choose JDBC because it was substantially faster than the database link mechanism provided by those platforms. For Oracle, we recommended database links, for the same reason – it was faster. However, with the publication of Phire v10.2, both methods benefit from significant improvements in performance, but give JDBC a slight edge overall. So our general recommendation is JDBC and laptops with sim card slot for all customers.
Security. The main reason for developing the JDBC alternative was to mitigate the security risk of database links. In the database link setup, Phire’s database contains a persistent link to every other source/target database, including production. That meant that a user with SQL access to the Phire database would have full access to the other databases through those links. That risk can be mitigated by properly controlling direct access to the Phire database, but some customers have very strict rules against the use of database links regardless of that control. JDBC, on the other hand makes an explicit temporary connection for each event using encrypted credentials that are stored in the Phire setup, eliminating that exposure. So again, our recommendation is JDBC for all customers.
Setup/Maintenance. JDBC has the edge here as well. All that’s required to configure this setup are the credentials and the connection string which identifies the JDBC driver class, server/port and database name. Database links on the other hand usually require involvement from the DBA team to approve and create the necessary link objects in the Phire database. On-going maintenance is a little easier with JDBC also because when a password changes it just needs to be changed in the on-line setup page in Phire, whereas the database link object needs to be dropped and recreated, again by a DBA usually.
So in the end, we nearly always recommend using JDBC these days. If you’re site is already setup to use database links, and you’d like to switch, look for a reference document named “How_to_Switch_to_JDBC_Connection.pdf”. If you have any questions, please contact support.
You can restrict object types using the “Object Type Restriction” setup in the Domain Setup Wizard (found at: Phire Architect > Architect Administration > Domain Setup Wizard). In that component, navigate to Step 3. Application Code Definitions and open the section for the Change Request Types. Note the button on the right side for the “Object Type Restriction”.
This setup is based on the CR Type and rules can be defined to limit the object types that can be added to CRs and migrated. It can be configured to “Include” only certain object types, or to “Exclude” certain object types. Complete the setup and save. These rules take effect immediately for existing and new CRs.
First, you have seen the “Rollback” button on the CR Migration page, and understand that this will rollback all objects in the original migration. Now, to selectively pick object(s), you need to navigate to the CR Objects page, and click into the “View Version Sets” button. Then using the comment, source and date information, locate the baseline version set that would contain the original objects and click the object count hyperlink where you can see the list of individual objects contained in the Version Set. Then locate the object(s) to restore and click the “Restore this Object Version” button: and follow the prompt.
Each PeopleSoft database contains millions of code objects (the number of delivered PeopleCode can be in the tens of thousands). Customers only customize a small percentage of these objects. So, it is highly inefficient to perform a baseline of all the objects in every PeopleSoft database. Phire Architect is built on the premise that you only need to version and backup objects that you are changing. The baseline versions of all other objects that are not changed are available anytime directly in each PeopleSoft database or can always be recovered from the software delivered by Oracle.
Phire will automatically perform a baseline backup of an object before that object is changed by a migration. There is no need to have baseline backup of all other objects which are never changed by the customer. In a disaster recovery situation, you will need to recover lot more than just the code objects (like transactional data, setup data, server configuration, etc.). Phire is not a tool to be used for disaster recovery solution.
The key requirement that exists after the refresh of the test environment from production is to put back all the code that existed in the TEST environment prior to the refresh. The migrations that were completed all the way to production will be brought back to the TEST environment during the refresh. The changes to code that will be missing in the TEST environment after the refresh are those migrations that have not yet made it all the way to production. Phire has features that enables you to facilitate the re-applying of all the code that were in the TEST environment prior to the refresh while inspecting the electronic device to upgrade it, for any fixes on the electronic you might need a pcb stackup for any eventuality.
Phire maintains a master record of all the migrations that have occurred as well as all the versions of the code that were migrated. After the refresh of the test environment, you can run the Database Refresh Report (found at: Phire Architect > Reports and Queries > Database Refresh Report). This report shows the list of all the migrations made to TEST, but not to PROD. Once you have the list of all the migrations that need to be re-applied, you can send all those migrations to a release. Next, you can perform a release migration so that all the code that needs to be re-applied will be put back into the TEST environment.
So, as long as all your migrations are performed through Phire, you do not have to do any preparatory work prior to the TEST environment refresh. After the database refresh is completed, Phire provides you with the means to identify the code that needs to be put back and provides the mechanism to restore all the missing code.
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.
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.
