SSI delayed sync agent
As explained in the "Handling Failed/Lost Index Updates" topic, index updates that were lost, or those that failed, are tracked through the YFS_Awaiting_Index table. Note that each index-update operation that needs to be done later asynchronously has a corresponding entry in this table. Each of these YFS_Awaiting_Index records represent one index-update operation that is pending, and corresponds to an entity record (such as, order/shipment) that is waiting to be indexed (hence the name awaiting-index). Once the index-update is done successfully, its corresponding record in this table is removed. Therefore, under steady run, this table will always have a number of records being created and deleted frequently. However, if there are certain records that are not removed from this table after several minutes of their creation, they may correspond to:
- Index update operations that were lost because a server JVM was forcefully killed.
- Index update operations that failed. In this case, the cause of the failure will be notified to you as described in the "Exception Handling" topic.
Each record in YFS_Awaiting_Index that is not removed automatically, called ‘stale records’ from here on, corresponds to an entity record that needs to be indexed. For example, if there is an entry in YFS_Awaiting_Index for the Order_Header table with entity key 2020123221211, this order has to be re-indexed. This agent monitors the YFS_Awaiting_Index table, and attempts to re-index such entries.
Since this table is always in a state of flux with each application/agent/integration server adding records and removing them almost every 3 seconds (since each index update is done after a 3-second delay, by default), this agent should only pick records from this table that are not being tracked by another application/agent/integration server. Therefore, this agent needs to be configured with an agent criteria parameter called OlderThanSeconds. Only those records in YFS_Awaiting_Index table that are older than the time (in seconds) configured through this criteria parameter will be processed by the agent. For example, if this is configured to be 600, all those records in this table that are older than 10 minutes will be processed by this agent.
Note the following:
- Since this agent fixes index inconsistencies, IBM® recommends that you set this agent to be triggered automatically. To accomplish this, you need to configure the Schedule Trigger Message property in the agent’s runtime properties. When you select Schedule Trigger Message, a corresponding text box is enabled in which you need to enter an interval value in minutes. When configured, the agent will be triggered automatically and will remove records from the AWAITING_INDEX table after a synchronization is successful. For example, based on your business needs, you may configure to trigger this agent every 60 minutes. If the agent criteria is configured with OlderThanSeconds=600, this agent will run every hour, and re-index all lost/failed index operations that were attempted more than 10 minutes ago.
- This agent is not an enterprise agent, and cannot be configured to run only for a particular enterprise.
- Each executeJob runs on a ‘batch’. Each such batch corresponds to a range of YFS_Awaiting_Index records from a particular colony. Further, batches from different colonies are interspersed. Therefore, if there are a huge number of YFS_Awaiting_Index records to be indexed after a long downtime of the index server, you can configure multiple agent threads for faster re-indexing.
- Since the agent runs for several records of this table in each
executeJob, multiple failure scenarios can exist:
- If critical problems are encountered that affect all index attempts (for example, if the index server is unreachable), the agent’s executeJob will fail altogether with an exception. Note that the original set of YFS_Awaiting_Index records will remain untouched.
- If individual documents fail, failure will be reported though the ‘Exception Notification’ framework, and another record will be inserted in the YFS_Awaiting_Index table so that another attempt can be made in the next agent run. In this case, the original YFS_Awaiting_Index records will be removed.
Attributes
| Attribute | Value |
|---|---|
| Base Transaction ID | SSI_DELAYED_SYNC |
| Base Process Type | General |
Criteria Parameters
| Parameter Name | Description |
|---|---|
| Action | Required. This parameter triggers the transaction. The default value is "Get". |
| BatchSize | Number of records to process in a single executeJob. The default value is 5000. |
| NumBatchesToBuffer | Number of records to return in one iteration of getJobs. The default value is 1000. |
| IndexName | Name of the index. For example: Order |
| OlderThanSeconds | Awaiting-index records older than the time specified here will be processed in a single run of the agent. Specify the time in seconds. The default is 600 seconds. |
| Colony Id | ColonyId When Colony Id is passed, the agent will be run for only that colony. It will process all YFS_AWAITING_INDEX records only in that colony, but for all the entity records of all enterprises belonging to that colony. |
| Collect Pending Jobs | This agent does not provide the pending jobs count for monitoring it in the System Management Console; hence, this parameter is set to N and is not modifiable. |
Events Raised
None
Statistics Tracked
None
Pending Job Count
None