Forum

Using Data Migration Workbench in Phire to produce a data set, got the above error. Is it referring to the Phire super-user or the individual using DMW?

As I know what version of Phire I have installed with a unix script or database. The query is if there is any script to be able to ask that As I know what version of Phire I have installed with a unix script or database. The query is if there is any script to be able to ask that question

How to configure project naming convention so we can migrate the same project definition name from source to target environments including the project definition properties and comments? For example – When developers create a PeopleSoft project and they need to update the Project definition properties (who, when, incident number, what changes or why its need etc). We need to migrate same project definition (including properties) to other environments.

We generally migrate projects two times a week on specific days/times, so the email notifications to migrators are not closely looked at until migration day.  However, we have created a new notification for when a project (script) has a need for an immediate run.  I know I can change the Subject line, but is there any way to add color/boldness so that is stands out among the many we receive?

At Phire, we closely follow the updates to PeopleTools published by Oracle/PeopleSoft.  As a result, we have historically published our support for new PeopleTools versions within 30 days of announcement by Oracle/ PeopleSoft.  Here is a table of past and current PeopleTools versions and what version of Phire supports each:

PT Version               Phire Version                 Availability

8.60                           v17.2.50                      Dec 2022
8.59                           v16.2.00                      Aug 2021
8.58                           v15.1.02                      Mar 2020
8.57                           v13.2.05                      Dec 2018
8.56                           v12.1.05                      Jul 2016
8.55                           v10.2.05                      Dec 2015
8.54                             v9.2.00                      Aug 2014
8.53                             v8.1.01                      Feb 2013
8.52                             v6.2.04                      Nov 2011
8.51                             v5.2.02                      Sep 2010
8.50                             v4.2.04                      Nov 2009

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.

Yes.  In the Phire email configuration, any email notification can include and “Additional To”, “Additional CC” or “Additional BCC” address.

For the Issue Tracking module, you’ll see the options on Page 3: Application Code Definitions of the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard).  The email notification link opens the details for each Issue Type.  Notice the grid tabs for “Additional To”, “Additional CC” or “Additional BCC”.  That entry can include a hard-coded email address, a listserv address or a reference to a user/role following the syntax described on the page help.

For the Change Request module, you’ll see the options on Page 13: Workflow Definitions of the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard).  The email notification link opens the details for each step in the workflow.  The same tabs are available here to enter an address or a user/role.

A powerful feature of Phire is its ability to automatically perform the App Designer “project build” following a migration.  This of course is the process of synchronizing the database tables/views/indexes with any updated record definitions in the project.  Without this feature in Phire, a user needs to log into the target environment using App Designer following a migration to manually perform the build.

The trick however, is that the PeopleTools App Designer program only operates on Windows, thus Phire needs a Windows server to run it on.  So there are two choices if you want to automate the project build in Phire – either put Phire on a Windows application server, or setup a Windows process scheduler.   If using a Windows app server then the build can run in-line as part of the migration.   If using a Unix/Linux app server, then a Windows process scheduler can be used.  In that setup then the build is submitted as a separate process on the scheduler after the migration is complete.

The choice is set on Page 2: Domain Definition in the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard).  The option “Build Method” includes options to perform the build on either the App Server or on the Process Scheduler (or None, if that’s your choice).  Additional setup for the process scheduler is shown if that choice is selected.

On the Migration page of the Change Request component are two buttons:  “Standard Migration” and “Ad hoc Migration”.

When entering a Standard Migration, the target is assumed based on the status of the workflow (see the Task page of the CR).  This generally represents the common migration path and business process that all work follows.  And controls in the workflow will prevent migration to a given target until prerequisite steps are completed, and then only by the assigned user or a member of the assigned role.  When complete, the workflow will automatically advance to indicate that the migration has occurred.

The Ad hoc Migration on the other hand, is intended to request a migration to a target that is not likely to be in the normal workflow, or in special circumstances to work outside of the controls of the workflow.  The Ad hoc Migration does not advance the workflow upon completion.  A common example is a training or sandbox database that is not normally part of the migration path, but occasionally needs to receive code as it moves through testing.  Another example is a test database that has been refreshed and needs a CR re-migrated – the ad hoc migration allows this to be done without having to fail the CR workflow back to the earlier migration step.  The list of available targets is setup on Page 14: Workflow Databases in the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard).  Additionally, only a user with permission to migrate to the selected target will be able to initiate the migration.

This list of available databases on the Ad hoc Migration prompt page is setup page at: Page 14: Workflow Databases in the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard).  Specifically, the databases that are marked with “Ad hoc Migration”.  To add more targets, just select and/or add the additional database entries and select the “Ad hoc Migration” check box.  This change takes effect immediately for all existing and newly created CRs.  Users with access to the CR can put in a request, but only users with permission to migrate to the selected target will be allowed to initiate the process.