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.

Hi.

We’d like to know if any of your customers have initiated a Workflow request from another PeopleSoft Instance.

We’d like to initiate one or more workflows from our HRMS PeopleSoft 9.2 (Tools 8.56.09) when an employee is hired.

We’d like to use PHIRE to handle the workflow requests for Active Directory setup, Application provisioning, badging, etc.

We may add PHIRE CRef’s into our HRMS instance so that the workflow can be monitored from within HCM but at this point we don’t think we want to add the PHIRE installation to our HRMS installation due to the potential for annual PUM impacts.  If you have examples of how this has been done we’d love to see it.

Thanks…

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?

This is in reference to the component found at Phire Architect > Change Requests > CR Workflow Reset.  It is designed to reset an open CR to the currently configured workflow setup.

Here is when you SHOULD use this component:  If you have made changes to the workflow steps and you want those changes to be reflected in an open CR.

As many Phire administrators know, some changes to the workflow only affect newly created CRs.  Workflow changes made on page 13 of the Domain Setup Wizard are primarily what this is referring to, including: the number and sequence of tasks, fail/skip options on tasks, default assignments and task trigger.  Most other changes take effect universally for all CRs without needing to reset, including changes to email setup, task assignment queue, workflow databases, security and database/server credentials.

Resetting the workflow preserves most of the history and status of a CR, but it is a harsh step to take in some ways.  Because all of the task level detail is removed and reloaded, there is some loss of data to be expected, including manual task assignments and task-level comments.  Tasks are reset and assignments redone as if starting the CR from scratch.  However, everything else is retained including CR-level history, objects and version history, migration and script history.

Here is when you SHOULD NOT use this component:  If the current task needs to be reset to another step.

If the CR is a position where nobody has the options to skip or fail to the correct current task, then it indicates a deficiency in the workflow setup itself.  Chances are the workflow steps need to be re-evaluated to be sure it best meets the business requirements.  Plus, someone on the team needs to have permission and options to skip/fail when necessary or else the workflow is too rigid.  At the very least, the Phire administrator should have the special permissions to “Skip Any Task” and “Fail Any Task” so that they can always re-position the current status.

As usual, if you have any questions about your particular setup, circumstance, or any of the options described here, don’t hesitate to contact Phire support to discuss it.

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.

The most common clarification that users need, is to understand that feature is reading a list of file names from a drive that’s visible from the Phire application server, that means it must be either a drive that’s local to that machine or is visible through a drive mapping.  Here are  a couple of examples of the syntax that works in many cases.

If source location it’s local on the application server, then this should work:

D:\psoft\FSDEVL\cbl\*.*

If it’s a mapped/shared drive, then it’s a little trickier, but something like this should work:

\\<sharename>\psoft\FSDEVL\cbl\*.*

First, leave the CR Type “active”, so that it continues to be visible in the searches.  Then go to the Row Level Security component (Phire Architect > Security Administration > Row Level Security) and remove the permission to “Create New CR” for that CR Type.  You’ll need to do that for each role that might have access to create a new CR.  In the end, the users will be able to search for and open the existing CRs with that type, but nobody will be able to create a new one.

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.

The option to show the domain throughout the application is on the configuration page:  Phire Architect > Architect Administration > License Code;  in the checkbox labeled “Display Domain Name”.  This will take effect immediately in many of the work list and result list pages in Phire.  With this turned off CR numbers for example will be shown like this: “CR000001”.  With this turned on, they will be displays like this:  “HCM-CR000001” (where “HCM” is the name of the domain).

For customers that have just one domain in their Phire implementation, it’s reasonable to turn this off and keep the display simple.  But if there are multiple domains in the implementation, then it is important to distinguish the domain associated with a CR or Issue and it make sense to turn it on.

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.