How error resolution works

From a question in SAP Joule to a proposal you can act on: the assistant finds the failed message, collects the evidence from your systems, weighs it, and answers with the root cause and the fix steps. A restart happens only after your explicit "yes".

The error resolution flow as a UML activity diagram. Click it to open it larger, then zoom in with + or a click on the part you want to read.

The steps

1. You ask in Joule, in your own words: by message ID, by business object ("sales order 122344") or for an interface and a period.

2. The assistant understands the request. It checks that this is an SAP operations question and reads the message, business object, interface and period from it, and your own observation if you added one ("I think the material master is missing"): a lead to check, never a fact. Other topics are declined politely.

3. It finds the failed message: by its ID, from an error list, or through the key fields of the business object in AIF. If several messages failed with different errors, it asks which one to resolve; the same error in several messages is resolved once and the others are listed.

4. It collects the evidence, read-only and in a fixed order:

   • AIF: the error log, the payload and the interface's configuration (checks, value mappings, actions), and other messages with the same error.
   • Known solutions: fixes that worked before for this error. A proven fix for the same error is answered at once, and the resolution ends there; fixes of similar errors become hints for the analysis. See Known solutions.
   • Landscape: the partner profile, port and destination the message went through.
   • SAP Integration Suite: errors and deployments of the iFlow on its path.
   • Grounding: your runbooks and guides that match the error.

   A source that is not connected, or does not answer in time, becomes a line under Limitations; the resolution goes on without it.

5. It judges the evidence with the language model on SAP AI Core: the verdict, the confidence, the root cause, the fix steps and whether a restart is safe. Only facts from the collected evidence can be cited.

6. It answers in a fixed format: the errors, the evidence, the root cause, numbered resolution steps, the similar known solutions that may fit, related messages, limitations, sources, and a Next suggestion.

7. A restart, only if you approve it. When a restart is safe, the answer offers it. The assistant asks once more, naming the message, and starts the restart only after your "yes".

8. The restart runs asynchronously. AIF runs the restart as a job, which can take minutes, so Joule does not wait for it:

   • Joule gets "Restart started" at once, and the conversation is not blocked.
   • The assistant watches the job in the background and keeps Joule up to date with "still running" every 30 seconds, so a long restart never times out or ends the conversation.
   • When AIF has finished, the result arrives in the same chat: succeeded, succeeded with warnings, or failed. You can also ask "status of the restart" at any time.

   The updates reach Joule as A2A push notifications. See Joule & A2A.

9. Your final decision. With known solutions on, a restart that succeeded is followed by the question "Did these steps fix it?". What you answer is what gets stored, so the next message with the same error is answered at once.

Cancelling a message

Some failed messages should not be processed at all: a duplicate, a test, an order already entered by hand. When an administrator has turned cancelling on, the assistant cancels one failed message, after you give the reason and approve it. A cancel is final: AIF does not process the message any more (status C); to process it later, the sender must send it again.

1. You ask: "cancel message 005056BF1EE259D16707A4B848200E6D", "cancel #2" (row 2 of the last error list) or "cancel it", or choose Cancel on a row of an error list.

2. The assistant checks first. Cancelling must be on, the message must be known and in error (status E), and the platform must offer the cancel. Otherwise it says why, and nothing is cancelled.

3. It asks for the reason, showing the message, its interface, its current status and its error. Choose one of the reasons, or type your own, from 3 to 255 characters:

   • Duplicate message
   • Corrected manually in SAP
   • No longer needed
   • Sent by mistake
   • Test message

   "No, keep it" ends here.

4. It asks for your approval: "Cancel this message now?", with the reason. Only "yes" cancels; any other reply keeps the message.

5. AIF cancels at once, so the result is the answer: no job and no waiting. In Joule it shows the success, then a card with the message, its interface, its status before and now, the reason, who asked, when it finished, the result, the correlation ID and the AIF log.

Each question expires after 15 minutes, and a new request closes it: nothing is cancelled then.

## Cancel message 005056BF1EE259D16707A4B848200E6D

Cancelling is final: AIF will not process the message any more. To process it later, the sender must send it again.

- Interface: ZSD/ORDERS v1
- Current status: E (error)
- Error: The material number for item 000010 could not be identified
- Reason: Duplicate message

Cancel this message now?

1. yes, cancel it
2. no, keep it

Behind the cancel

• The switches. The agent's setting Cancel AIF messages (AIF_CANCEL_ENABLED) and the MCP server's own AIF_CANCEL_ENABLED, set at deploy time with the parameter aif-cancel-enabled. Both are off by default; the platform's switch is turned on only with the AIF mock until SAP's own AIF cancel API is verified. See Settings.
• The scope. Restart covers both the restart and the cancel; there is no scope of its own for the cancel. Users get it with the role collection AIF MCP Restart, the assistant with the platform deploy. See Roles & access.
• The tool and the API. The assistant calls the MCP tool aif_cancel_message on /mcp/aif. Other tools can use the REST API: POST /api/aif/v1/messages/{msgGuid}/cancel with a required reason (3 to 255 printable characters) and, optionally, onBehalfOf, the user the caller acts for. It answers at once: the message cancelled, the cancel refused (the message is not in error, or its restart still runs) or failed.
• The audit. Every cancel is written to the MCP server's audit log with the message, the interface, who asked and through which caller, the correlation ID, the reason and the outcome; never the message's data.

What an answer looks like

A shortened, illustrative proposal:

## Resolution proposal: ZSD/ORDERS v1

The material number for item 000010 could not be identified.

- Message: 005056BF1EE259D16707A4B848200E6D
- Business object: sales order 122344 (ZSD/ORDERS v1)
- Confidence: High

### Root cause
- The customer's material number in the order is not assigned to a material.

### Resolution steps
1. Assign the customer's material number to the material.
2. Restart the message.

### Limitations
- SAP Integration Suite is not connected, so the iFlow was not checked.

Next:
- Reply "restart" to restart this message (I ask for your approval first)

Related

• Skills & example prompts: every skill, with prompts to try.
• Architecture: where the agent, the MCP servers and governance sit.
• Known solutions: fixes that worked before, and your final decision.
• Settings: turning restarts and cancels on, and how long the assistant waits for the result of a restart.