Forum

With the recent announcement of security vulnerabilities in the Apache Log4j and Log4Shell logging libraries, we have investigated Phire’s exposure and here is our recommendation.

Phire does not make use of the Log4j or Log4shell libraries, so based on that we are not providing any patches or making any changes to our delivery.

However, since Phire runs in a PeopleTools environment, we are recommending that customers follow Oracle recommendations for mitigating the risk in the web/app/prcs server configurations, outlined in Doc ID 2828073.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=209125163936738&id=2828073.1

We’ll continue to monitor the situation.

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

Do you need to upgrade ptools from pt8.51 to later version if you are upgrading phire from 9.2 to release 11.1?

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

For example, can a Project Build be done through Phire that will handle a project that contains:

1. Create a new table
2. Alter a table to contain new columns
3. Alter a table to change column definitions
4. Alter a table to drop columns that contain data
5. Migrate a table with no structural differences

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.

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.