ECC Queue inputs are not marked as Processing or Processed if the upper/lower case of the MID Server name in the agent field is not exactly the same as the input - Known Error

ECC Queue inputs are not marked as Processing or Processed if the upper/lower case of the MID Server name in the agent field is not exactly the same as the input Description A MID Server will fetch and execute ecc_queue output records based on the MID Server name in the agent field, regardless of the upper/lower case of the name. However since Utah Patch 2, the queue.processing Input mid server name is compared with the Output name, and only if there is an exact case sensitive match would the Business rule "ECC Queue – mark outputs state" set the status from Ready to Processing. Similarly, when an Input for the probe comes in, the Business rule "ECC Queue – mark outputs processed" does the same check and won't set the Output to Processed state.

Symptom: The same ecc_queue output can run thousands of times in the 2 hours since being inserted. The default query window when picking up new jobs is 2 hours, after which it isn;t run but remains in Ready state. If the MID Server is restarted, it will run the Out put once more.

This could happen if a a script is hard-coding the MID Server name, or perhaps takes it from a system property value, and that is not the exact same case sensitive name of the MID Server record.

Steps to Reproduce

On a Utah Patch 2 or later instance (that has the version of the business rule with the fix for PRB1641991) Create a ecc_queue output where the agent includes the mid server name is not identical to the ecc_agent record. e.g. mid.server.PROD_DISCO_MID instead of mid.server.Prod_Disco_MID Actual behaviour: The mid server will fetch and run the job more than once, so multiple Inputs for the same output will be seen. The Output remains in Ready state.

Expected behaviour: The agent field case doesn't matter when picking up jobs, so should also not matter when processing inputs.

Vancouver release moves this logic out of the business rules and into Java (PRB1599282/STRY55230818), but may have the same issue.

Workaround This problem is currently under review and targeted to be fixed in a future release. Subscribe to this Known Error article to receive notifications when more information will be available.

The workaround is to ensure the 'agent' field value of the ecc_queue output record is using the MID Server name in the exact same case as it is entered in the MID Server form [ecc_agent]. Search your system properties and code for the mid server name, and correct it.

If a MID is currently re-running ecc_queue outputs, then set the Output ecc_queue record to Processed to stop it re-running the job.