Policy Update Requests Process

This page documents the process that uses policy update requests to create a new policy or update an existing one.

Receive the Policy Update Requests for Processing

The application receives policy update requests either as a single update request for a policy or multiple update requests within a file for multiple policies through Policy Update Requests Integration Point. The integration point performs an initial validation check to create the policy update requests and adds the valid requests to the queue for processing.

Processing Queued Policy Update Requests

The process starts by collecting all the policy update requests in the Queued status and performs:

The processing of policy update requests runs at set intervals automatically using the polling process or by invoking an activity manually. See Configurable Properties of policy update request for more details.

Filter out the Update Requests with Disabled Auto-Update

The application filters out any matched policy update requests where the disableUpdateFromQueue? set as true for the policy, which means paused auto-updates for the policy. Such cases happen when there are failed update requests in the queue or when manually pausing the auto-update process.

Sort the Policy Update Requests

The filtered update requests from the previous step are now sorted based on the following criteria:

  1. The available policy gid within the policy update request.

    • If gid is unavailable on the update request, then the process sorts the update requests based on the available policy code within the policy update request.

  2. After the policy update requests for the same policies are together, they are further sorted based on the creation date and time to process in the order that they were received.

    • The creation date and time for individual requests.

    • The creation date and time of the data file set in the ascending order of the file-based requests.

      • The policy update request sequence within the data file set.

These sorting methods ensure that the policy update requests are processed in the correct order.

Create Batches

The sorted policy update requests from the previous step are split across multiple batches for processing with a fixed number of policy update requests in each batch. This sorting is based on the ohi.policyupdaterequestimport.filereader.chunk.size property. Each batch contains update requests for one or more policies. A separate processing activity is spawned for each batch.

All update requests of a single policy are always part of the same batch.

Process Individual Update Requests

After sorting the update requests, the activity starts the update process. Each update request updates an existing policy or creates a new policy. For each update request in the queue, the process performs the following steps:

Matching the Policy

The process populates the policy gid and matched policy code for the policy update request, that is it checks if a matching policy pre-exists in the application.

If the policy gid of the update request is null, that is no matching policy was identified when creating the policy update request object:

  • The application checks if a matching policy exists based on the available policy code and the policy identifier type code.

  • If the application identifies a matching policy, the policy gid on the update request is set as the matched policy gid.

This additional check ensures that policy gid is populated in case the policy was created after the application received the policy update request. For example, when an earlier update request in the file created the policy.

Recheck the Update Request Status

Before applying the update request, the process rechecks the update request status, that is if the policy update request status is Queued. The additional checks prevent processing any policy update requests with changed status since the start of the processing. For example, changes in the update request status to Rejected using the Reject Policy Update Request or when the enrollment file was rejected. If the policy update request status has changed to anything other than the queued status, the process skips the current policy update request and moves to the next request in the queue.

Check Enrollment File Status

The process checks the enrollment file status linked to the policy update request. If the enrollment file status is Rejected, the update request is also marked as Rejected and the update is not applied to the policy.

Create a New Policy

The process treats the policy update request with an unidentified matching policy as a new policy request. The process tries to create a new policy using the received payload.

The process creates a new policy using the payload from the policy update request. If the policy is created successfully:

  • The policy gid for the update request is set to the policy gid from the newly-created policy.

  • The policy-update request to a Loaded status.

  • The last update failed indicator is set to false.

  • The matched policy code on the policy update request is set to the policy code.

If the process does not create a new policy, for example, when there is a technical or functional error:

  • The policy update request to a Failed status.

  • Error details are attached to the policy update request history.

  • The last update failed indicator is set to true for the policy update request.

Update an Existing Policy

For the policy update requests with a matching policy, that is policy gid is not empty, the process uses the policy update request to update the matching policy. The process rechecks the policy flag policy.attachedpolicydata.disableUpdateFromQueue. It must be set to false to enable updates to a policy. If the flag has the value true, the auto-update process is paused. The update does not apply to the policy, and the process moves to the next update request in the queue. This occurs when a previous update request for the same policy fails, or you have paused the auto updates.

The policy in patch integration point is used to process the update requests. The enrollment file linked to the policy update request is also updated to reflect the number of received policy counts and the received enrollment counts on the enrollment file itself.

Updating a policy in the Approved or Cancelled status using a policy update request:

  1. The process starts by applying the update request payload to the matched policy.

  2. If the update is applied successfully, then a new version of the policy is created with the changes. The following steps are performed:

    • The policy update request status is changed to Loaded.

    • The last update failed indicator is set to false.

    • The matched policy code on the policy update request is set to the policy code.

  3. If the update process fails from a functional issue, for example, when there is a brand name mismatch or in other similar situations,

    • Policy update request status to a Failed status.

    • Error details are attached to the policy update request history.

    • The last update failed indicator is set to be true for the policy update request.

    • The policy.attachedpolicydata.disableUpdateFromQueue? indicator is set to true, that is avoids further processing of updates until the failed update is rejected or re-queued.

    • The policy remains in an approved or canceled state.

Updating a policy in an Edit, Pended, Pending File Review, or In Process status using update requests:

  1. If the enrollment file linked to the current policy matches the enrollment file from the policy update request:

    • The process uses the payload from the request to update the policy.

    • If the policy is updated successfully:

      • The policy update request to a Loaded status.

      • The last update failed indicator is set to false.

      • The matched policy code on the policy update request is set to the policy code.

  2. If the update process fails from a functional issue, for example, when there is a brand name mismatch or any other similar situations:

    • The policy update request status to a Failed status.

    • Error details are attached to the policy update request history.

    • The last update failed indicator is set to be true for the policy update request.

    • The Policy.attachedpolicydata.disableUpdateFromQueue? indicator is set to TRUE, that is to avoid processing of update until the failed update is rejected or re-queued.

    • The policy remains in its pre-existing state.

  3. The case of enrollment file mismatch between current and previously Loaded policy update requests:

    • The update request is not used to update the policy, keeping the request status as Queued. The process moves to the next policy update request in the queue.

    • NOTE: When the current version of the policy does not refer to an enrollment file and the update request refers to an enrollment file or vice versa, this is a case of enrollment file mismatch. The current update request is skipped in such cases.

Submitting Policy for Processing

After processing all the policy update requests in the queue, policies with successful updates are submitted. The submit flag determines whether a policy is submitted. The value of the flag must be true for the last-processed policy update request that was successful and the request must be in the Loaded status. See Process Policy for process update request status transition when the policy status is Approved.

Configurable Properties

The processing of policy update requests runs automatically by enabling the polling process. If the polling process is enabled, configurable properties for polling interval and batch size impact the processing of policy update requests.

ohi.policyupdaterequest.polling.enabled

  • Used to enable the polling process for queued policy update requests.

  • Enabling polling automates the policy update requests at a set interval without requiring a user to invoke the PROCESS_POLICY_UPDATE_REQUESTS global activity.

  • Allowed values: true and false.

  • Default: false.

The PROCESS_POLICY_UPDATE_REQUESTS global activity cannot be invoked manually if the ohi.policyupdaterequest.polling.enabled is set to be true.

ohi.policyupdaterequest.polling.interval

  • The polling interval is defined in seconds. By decreasing the interval, the queued policy update requests are picked up earlier for processing.

  • Only applicable if the system property ohi.policyupdaterequest.polling.enabled is set to true.

  • Allowed values: Integers of 1 or a higher number.

  • Default value: 60.

ohi.policyupdaterequestimport.filereader.chunk.size

  • A separate processing activity is spawned for processing a chunk or batch of policy update requests.

  • This property determines the number of policy update requests in each chunk.

Monitoring the Process Policy Update Request Activity

The PROCESS_POLICY_UPDATE_REQUESTS global activity is used for the processing of policy update requests. The messages created by this activity are used to monitor the process and errors, if any.