Case 1: Submission of a PDC Policy

• When you submit a policy, the first step is that the PDC engine determines which entities are assigned to that policy based on the entity type and criteria defined within the policy setup.

• Next, based on the fields in the Policy's underlying Field Groups, a copy of only those field values from the latest effective date are stored in the history table (for whichever date the policy is run for).

• In the next step, all the applicable validations and enrichments are processed and exception messages are created for failed validations.

• Future dated overrides are picked up and processed if the override date matches the PDC processing effective date.

• At last, each entity is assigned a release level based on the passed/failed validations.

• Field values which passes the validations are pushed to the composite record.

• Field values which fails the validations are not stored in the composite record until the exception is fixed or released.
  Note: Any field on the composite record that is NOT part of the policy is not overwritten or nullified. PDC only interacts with fields that are contained within the policy. However, history is not maintained for fields that are not in the policy's field groups, so it is important to include all necessary maintained fields in the policy before the first processing is kicked off.

Case 2: Modifying an Entity

• When you modify an entity in Entity Details workspace, the engine synchronously, that is without submitting the overall policy, processes the new override values, applies any validations or authorizations based on the options in the policy that governs the entity.

• If there are no exceptions, the new values are pushed to the history records. Furthermore, if changes are made to the most recent history record (that is not later than the current date), the new value is updated to the composite record.

• If exceptions are triggered for the current effective date the new data is not updated to the composite record until the issues are resolved.
  Note: The new value for the field are updated to the history tables for whichever effective dates it is edited in the Entity Details workspace. You can edit more than one effective date at a time.

Case 3: Entity uploaded through Message Stream or Uploader

• The core standard entity uploader stream for loading entity data systematically is available in Message Center (eagle_default_in_csv_entity). 

• To properly utilize the message stream, the incoming records must have the value for Tag 989 = PDC. The support of new flag is updated in eagleml streams for entity upload (eagle_ml_2.0_default_in_xml_entity).

• This ensures that (for entities that existed previously), the new incoming history records do not overwrite the master record. Note: Please note once the first run of a policy in PDC is triggered, an entity's master record is maintained by PDC only.

• Based on the triggered PDC event, the engine processes the entity and applies any validations or authorizations based on the options in the policy that governs the entity and in the end assigns a release level to the entity.

Regular vs Delta Mode

Generally, you can process PDC policy in two ways: regular (non-delta) and delta mode (process new and/or updated entities only). PDC events that are run in regular/non-delta mode for a specific date will process all entities governed by that policy for the specified date.

• The event will create new history records by cloning the most recent history record prior to the run date of each entity.

• Next, the various workflow parameters from the policy are applied against the new/current record. Fields that pass validations are moved into the history tables for that current effective date.

• In addition, if the build date is now the most recent history record, then the values are updated to the composite (non-history tables).

• Fields which do not pass the validation are not moved to the history or composite record until they are released or fixed.

In summary, the best practices for running PDC processing is to run each policy in non-delta mode on the 'conversion day' and then delta mode (not policy specific) from that point forward, as a scheduled event. 

Triggering PDC Event

You can trigger PDC processing event in 3 ways.

• Manually editing an entity through PDC User Interface. 
  When you edit and submit an entity though the Entity Details workspace, the engine automatically starts processing the entity.
  There is no need to kick off the engine (run a policy/event) when you manually override a field for an entity. When you submit manual overrides through the User Interface, the new field values are processed automatically without the need to run the policy separately (synchronous processing).

• Through Submit Policy option in Setup > Policy workspace.
  This action submits the PDC processing for all entities governed by that policy. You can submit the policy either in Delta or Non-Delta mode. But after the 'conversion date', you do not need to run the specific policies manually.

• Schedule a PDC event via Automation Center. 
  You can schedule the events to run with the following options:

  • Delta Mode. The system runs all the enabled policies and processes entities that is modified since the last time. 

  • Policies. This allows you to run the specific selected policies and also has a delta mode if needed.

  • Entities. This allows you to pick specific entities to process regardless of what policy they belong to. This mode is mostly for use with setting up process initiators so that if a new fund is updated via an uploader, you can trigger a PDC event to run that one updated entity.