Thursday May 23, 2013

Explanation of History Settings for P6 Analytics

This blog applies primarily to P6 Analytics\P6 Reporting Database 3.1.  As of 3.1, history was introduced at a daily level at the activity level.  Activity level history existed as of P6 Analytics 2.0\P6 Reporting Database 3.0 but was only at the interval level of week, or higher. The settings in P6 for history level and history interval haven't really changed too much, but their meaning has changed.  These history settings are on the project level and are defined project by project.  This gives flexibility to include lower levels of history for ONLY those projects that require it. These settings are defined on the Project Preferences section of P6. 

Choosing activity level history can cause your data warehouse to grow extensively based on the amount of changes and size of projects.  If setting projects on activity level history you should first review the Planning and Sizing guide and make sure you have the required space of growth.

 If you choose history level = Activity (internally HL_Task), then this project now has Daily history turned on as well as:

- Type 2 slowly changing dimensions for all aspects of this project
- Activity spread data on daily level and historical facts
- Resource assignment spread data on the daily level and historical facts.  
This can produce a large amount of data. If the project finishes or gets to a point where you no longer need to see this level of granularity it is recommended to turn down the level of history to either Project or WBS.

If you have chosen history level of Activity, the setting for history interval now becomes relevant for the Project and WBS history.  You can choose week, month, etc. for the interval of time to be captured for Project and WBS history. This history interval does not apply to the Activity history because Activity is always Daily once chosen.

If you choose Project or WBS level history the history interval setting would apply.  History always rounds up. If you choose Activity, you automatically are opted in for Project and WBS history also.  If you choose WBS history you get Project history as well.  

Friday May 03, 2013

Extended Schema Data- How to force specific projects at a designated time

As you know the Extended Schema services (Project service specifically) runs on a designated time interval based on your Publish Project settings. This could be set to run every 1 min (default), and at this time the 'arbiter' runs and determines which projects need to be queued up to be processed. The arbiter determines this by evaluating each project that has PX_ENABLE_PUBLICATION_FLAG set to 'Y', and threshold of changes on this project or the threshold of time has been crossed. In your database you can see how many changes there are on the specific project by reviewing your PLPROJREF table in the Admuser schema.

Another reason why a project would be queued up is because you right clicked on the project and choose Publish Now.  When you choose publish now what actually occurs is a time stamp is made on the PX_NEXT_DATE field for that project row in the PROJECT table.  In the application there is not a way to separate out projects into different batches that may follow different publish project settings.  The design behind this was to allow data to continually be updating in the system at these different times when the project may have an appropriate amount of changes, time has passed, or you need it now then to calculate the project.  Let the system take care of itself and keep the data up to date in a near real time environment.  On the P6 Analytics\P6 Reporting Database side controls were added such as filters, and additional data sources to allow you to control what projects get pulled over and possibly setting them up on different ETL runs. 

A scenario that was recently proposed was this, I have a group of projects under a specific EPS.  I want these projects to be published at midnight, every night, even if they did not cross a threshold. But all other projects should obey the publish project settings.  One way to accomplish this is through the back end. 

1- determine a list of these projects and get the project id for these projects. You may even want to determine this list of project id's dynamically in case any other new projects are added under this EPS.

2- Put together an update statement that will update those projects and set the PX_NEXT_DATE = sysdate for these project rows. 

3- Have a batch or cron job that will run every night at midnight that executes step 1 and step 2.

By stamping the PX_NEXT_DATE with sysdate you are basically saying publish now.  The next time the arbiter runs it will add those projects to the queue.  Be careful because there is no limit to the number of projects that can be added through this method. The queue could become full and may take some time to process all the projects if there are a lot. Using this approach gives you some control of forcing certain groups of projects to be automatically published at some predetermined time regardless of threshold.

Provide new information on Primavera Analytics and Data Warehouse


« May 2013 »