Inbound Work Order Interface Fails Intermittently
An external dispatch system sends about 400 work orders per hour to Maximo v8 through the MXWO enterprise service. The service uses Add/Change processing and is configured to skip duplicates. Roughly 5% of messages end in ERROR with a message that WOPRIORITY is not a valid value. The external system sends priority codes 1 through 9. Maximo's WOPRIORITY domain contains 1 through 5 and a custom value 9 added last month for emergency work. The failures began after the domain change. A separate, expected error occurs when ASSETNUM does not exist. Message Tracking shows the failed messages, and Message Reprocessing is available but has not been used. The dispatch vendor says its codes are correct and refuses to change them. Operations wants the failures stopped before the next morning shift.
1. How would you isolate whether this is a domain-mapping problem, an object-structure processing problem, or a stale cache?
Read the worked answer
Open one failed message in Message Tracking and read the full error, not just the summary. Extract the inbound WOPRIORITY value and compare it with the current WOPRIORITY domain. If codes 1 through 5 and 9 succeed while 6 through 8 fail, the pattern points to domain mapping, not object-structure processing. If 9 also fails even though it exists in the domain, suspect a stale domain cache or an environment where the change was not propagated.
Next, inspect the MXWO object structure processing rules. Look for a set-value, default, or validation rule that could override or reject WOPRIORITY before the domain check. Confirm the enterprise service is using the object structure and service you think it is. Finally, replay a single failed message through Message Reprocessing after the suspected fix. A successful replay of 6 through 8 proves the mapping; a failure on 9 alone points back to cache or publication refresh.
2. What are the viable fixes, and what criteria decide among them?
Read the worked answer
The options are to extend the WOPRIORITY domain to include 6 through 8 with business-approved descriptions, to map 6 through 8 to existing Maximo priorities in the object structure, or to require the dispatch vendor to send only supported values. A fourth option, silently defaulting unknown values to 5, is risky because it destroys the emergency signal.
Choose based on semantics and downstream impact. Ask whether 6 through 8 are genuine business priorities that reports, SLAs, mobile users, and downstream systems must distinguish. If they are, extend the domain and refresh the cache, then verify every application that uses WOPRIORITY. If they are vendor-specific codes that mean the same as existing Maximo values, map them explicitly and document the mapping. Reject the silent-default option unless the business formally accepts the loss of meaning. Also check whether WOPRIORITY is used in priority matrices or escalations before adding values.
3. How would you validate and monitor the chosen fix without waiting for the next 400-message batch?
Read the worked answer
Use Message Reprocessing to replay a controlled sample: one message for each priority code, including 6, 7, and 8, plus a known-good 9. Check the reprocessed message status and confirm the resulting work order priority and description. Send a fresh test message through the same enterprise service to prove the path is not relying on reprocessing alone.
Then add monitoring before the next shift. Track ERROR counts in Message Tracking by error text and by external system. Set an alert threshold well below 5% so a regression is visible quickly. Confirm the duplicate-skip behavior still works with a duplicate test message. Document the domain or mapping change and the cache refresh step, because the next administrator will need to know that a domain edit alone is not the full fix.