PX Services: Project Publication Arbiter Settings

Project Publication (PX) service is a process to provide near real-time operational reporting data while not continually churning over each and every row updated in P6. Much better to perform calculations on a batch of rows to maximize efficiency of the application server. The process we call The Arbiter facilitates this by queuing project to be recalculated in a timely and configurable fashion. The process and settings around Arbiter are a source of confusion and mystery. I will try to shed some light on them below.

Arbiter is a database stored procedure. It is scheduled, using the P6 Job Service framework, as a reoccurring job that is usually run once every minute. It is important to note that this job is the process that puts projects on the queue; it is not the actual recalculation of the project data. The job can be viewed in the JOBSVC table:

alter session set nls_date_format = 'mm.dd.yy hh24:mi:ss'
column job_name format a20

select job_name , job_type, status_code, last_run_date
, recur_data
from jobsvc
where job_type = 'JT_ProjectArbiter'

JOB_NAME             JOB_TYPE             STATUS_CODE          LAST_RUN_DATE
-------------------- -------------------- -------------------- -----------------
RECUR_DATA
--------------------------------------------------------------------------------
PxArbiterRECUR       JT_ProjectArbiter    JS_Complete          04.16.13 07:23:29
MinuteOfDay=1,DayOfWeek=0,WeekOrdinal=0,DaysInPeriod=60,PredecessorBool=0 

The Arbiter stored procedure performs two broad functions. The first is only relevant to the initial bootstrapping of the system. After upgrading from a pre-8.1 version of P6, the projects need to be calculated for the first time and the Arbiter will schedule these project if they have not been updated yet (Details of this will be a subject of a later post). The second process continually queues projects for update. This is controlled by settings in Administer->Application Settings->Services section of the P6 application. The screen has three options the affect when a project is queued.

Publish Project Settings

The first setting (Publish projects every) will change the recur interval on the JOBSVC job. The other two control how often each project is published. You can always "demand" immediate recalculation of the project from the EPS page. This will bypass all other logic and the Arbiter will queue the job immediately on its next run. After this happens, the two settings above, Number of changes exceeds and Time since last publication exceeds, are used to find any other projects to queue. If the Publish Project flag (on the project record) is not set, then the project is never considered for publication.

Number of changes exceeds

A reference count query is performed on the tables TASK (Activities), TASKRSRC (Resource Assignments) and TASKPRED (Relationships). This counts any records with UPDATE_DATE between the last time Arbiter ran and the current time. A single record updated multiple times during this period will only count once. The results are stored in PLPROJREF. 

SQL> select * from plprojref;

   PROJ_ID    REF_CNT LAST_QUEUED_DATE
---------- ---------- -----------------
      3869         20 04.16.13 07:16:07
      3870        101 04.16.13 07:16:07
      4417          0 04.16.13 07:16:07
....

If the REF_CNT value exceeds the setting (set to 100 above), the project will be queued. In this case PROJ_ID=3870 will be queued. Once the project is queued, the value of LAST_QUEUED_DATE is updated and the REF_CNT is reset to 0.

Time since last publication exceeds

If the project is not queued based on the REF_CNT, the Arbiter considers the delta between the current time (SYSDATE) and the LAST_QUEUE_DATE in PLPROJREF. This happens only if REF_CNT is greater than 0 to prevent idle projects from being queued. In this example there is a project with only 12 changes but it will be queued because more than eight hours have passed (the setting value of 8h).

SQL> select sysdate from dual;

SYSDATE
-----------------
04.16.13 16:35:03

SQL> select * from plprojref;

   PROJ_ID    REF_CNT LAST_QUEUED_DATE
---------- ---------- -----------------
      3575          0 04.16.13 10:22:18
      3576         12 04.16.13 07:16:07
      3577          0 04.16.13 12:15:11

....

In this case PROJ_ID=3576 will be queued. The value of REF_CNT will be reset to 0 and the LAST_QUEUE_DATE updated.

I hope this starts to clear up some of the confusion about project queuing in PX. The Arbiter and related settings are just one aspect of the PX Services and I will get deeper into these services in future posts.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

An insider view of the technology behind the Primavera product suite.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today