Archive for Change Requests

Where do you setup the list of available Ad hoc Migration targets?

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.


java.lang.NullPointerException error when running Phire compare

We get the following error when attempting to run a Phire compare:

Java Exception: java.lang.NullPointerException: during call of (2,763) PHI_FUNCLIB.PHI_COMPARE.FieldFormula  Name:PHI_RunCompare

What causes this and how can this be resolved?

Comments (1)

How to use the file directory import feature?

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:


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



How to setup so nobody can create a new CR using a particular CR Type?

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.


How to set the default for the CR Type?

It is quite easy to set the default CR Type using 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.  Select the one to be used as the default, and save.  Alternatively, you can have no default forcing the user to select from the available list before saving a new CR the first time.


How to restrict object types allowed in a Phire CR?

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.


How to rollback a single object versus a whole migration?

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.


How to prevent Issue status from being updated by the CR?

You can prevent the update of the issue status as the CR status changes by updating the workflow definition and setting all the Issue Status fields to blank.

Phire Architect > Architect Administration > Administer Workflow, select the Domain and CR Type. For each step, blank out the Issue Status field.

If you have one CR to multiple Issue relationship, we recommend that you do not have the CR automatically change the status of the Issues. Instead, we recommend that you disable this feature using the instructions above and manually update the status of each of the associated issues.


How to handle refresh of a TEST environment from production?

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.

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.

Comments (2)

How to handle development starting in multiple databases?

You can accomplish what you want in your current release by following these steps.

1. Remove the source database name from the workflow definition for the “Add Objects to CR” step. This way, development can be done from any database and the developer can add the objects from App Designer project that is found in any database.  Navigate to Step 13: Workflow Definitions in the Domain Setup Wizard and Edit Details of the “Add Objects to CR” step and remove the value in the “Source DB” field.

2.  Remove the requirement for the source database in the “Create Migration Set” step. Navigate to Step 4: Task Code Definitions in the Domain Setup Wizard. Uncheck the “Source DB Required?” checkbox next to the “Create Migration Set” Task Name.

3. Remove the source database from the “Create Migration Set” step in the workflow. Navigate to Step 13: Workflow Definitions in the Domain Setup Wizard and Edit Details of the “Create Migration Set” step and remove the value in the “Source DB” field.

4. When performing the “Create Migration Set” step within a CR, the developer will now need to populate the Source Database at run-time. The developer can specify the Source database by clicking the “Additional Details” tab within the “Tasks” tab of the CR. The Source DB will be enabled and they can choose which database appears.

5. Define which databases are available for Add Objects and Create Migration Set.  Go to step 14: Workflow Databases and add any database and specify which ones you want to make available for Add Objects and Create Migration Set.


« Previous Page« Previous entries « Previous Page · Next Page » Next entries »Next Page »