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:
-
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.
-
-
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 tofalse
to enable updates to a policy. If the flag has the valuetrue
, 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:
-
The process starts by applying the update request payload to the matched policy.
-
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.
-
-
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 totrue
, 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:
-
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.
-
-
-
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 toTRUE
, that is to avoid processing of update until the failed update is rejected or re-queued. -
The policy remains in its pre-existing state.
-
-
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 totrue
. -
Allowed values: Integers of 1 or a higher number.
-
Default value: 60.