AMI Message Cockpit

This is the AMI Message Cockpit running entirely in your browser against generated data. No SAP system is connected. Meter numbers, contract accounts, disconnection documents and request ids are synthetic and resemble nothing in any real landscape.

Every service name comes from the SAP standard AMI service catalogue — SAP standard enterprise services only, nothing bespoke. Hover any service chip to see the technical name. The disconnection status codes are the real EDISCACT-ORDSTATE values (02, 04, 12, 20, 26), the mismatch codes are the real the LRN mismatch report codes (11, 22, 55, 77, 88, 99), and the slotting follows the the dunning slotting job logic.

Configuration, not code. The threshold is keyed exactly like the monitoring config table — TRANS_ID 'MONITOR_THRESHOLD', IN_VALUE 'INFLIGHT_AGE_MIN' — the same row the RCD monitoring job reads. The cockpit adds per-service and per-process-area overrides on top, because one global number cannot serve both a reconnection and a bulk replication. Open any message and the SLA line shows from config. The numbers in this demo are placeholders until the production OUT_VALUE is loaded.

A No-Cut entry is a date, not an area rule. Event type (Scheduled, Adhoc, Same-day), day type (Non-Disconnection Day, Disconnection with Contact), applicability (All, District, City), a reason code and remarks capped at 30 characters. Past dates are refused; a date more than 18 months out warns and has to be accepted. Multiple dates can go in at once, and a repeat-until date replicates the same day of week.

Add, Edit and Cancel need the No-Cut maintenance role. Everyone else sees the same screen with every control disabled. Edit takes exactly one entry; Cancel takes several and asks for confirmation, because cancelling means disconnections may proceed on that date. History reveals cancelled entries, which the default view hides. Adding or cancelling a Same-day or no-contact entry pages the distribution list, including pager IDs — those two change what happens to customers today.

At run time the entry is matched to the document's service address. The city comes from the join the dunning slotting job already performs — EVER → EANL → EVBS → ILOA → ADRC — which gives the service address of the premise, not the bill-to address on the business partner. A customer can be billed in one place and metered in another, and a No-Cut has to follow the meter.

The banner is above every tab because extreme weather is the condition most likely to make a correct-looking disconnection run the wrong thing to do. It is not decoration: an EXTREME or SEVERE county forecast sets a weather lock and Release is disabled. A WATCH is shown but does not block — a watch means conditions are possible, not present.

A manual lock is separate and needs a reason. It holds every release regardless of county, for the things the forecast feed cannot see: a billing defect, a head end outage, a regulatory instruction. The manual control only adds a lock — clearing a weather lock by hand is not a judgement an operator should be able to make, so it clears when the forecast clears.

A remote disconnection is not a bare command. An adhoc disconnection creates a disconnection document at status 13 (to be requested) with process variant CUST, and the connection status change service is raised against that document. CUST rather than DUNN so the dunning follow-up rules do not pick up something an operator raised by hand.

An adhoc reconnection goes the other way: it finds the open disconnection document and creates the reconnection request against it, moving the document to status 26. Keys with no open document are named before you send and rejected rather than dispatched — a reconnection with no disconnection behind it has nothing to close out and the write-back has nowhere to land.

Cancel disconnection activity, on any disconnection in the drawer, does three things together: cancels the activity, closes the document at status 40, and resets the dunning cycle so the account is not left at a dunning level with nothing behind it. If the command already reached the head end, cancelling in S/4 does not recall it — that is what the service order option is for.

Every remote disconnection and reconnection carries a user status alongside the system status — the lifecycle the business tracks, from the status profile on the disconnection document:

It does not replace the ORDSTATE, and the two must never be conflated: several numbers collide with different meanings — user status 26 is Disconnection Inflight, ORDSTATE 26 is reconnection to be requested. That is why the cockpit always shows the user status as a labelled US nn tag and never as a bare number.

21 and 29 are distinct moments on purpose: 21 is the head end confirming supply is physically back on; 29 is the completion of the document afterwards by the daily job. Watch a reconnection confirm in the monitor and its status moves 28 → 21 → 29 as the document closes.

View all AMI messages from a table or a CDS view?

A CDS view, not the table. ZC_AMI_MessageStatus over TEAMI_LOG_DATA joined to EDISCDOC/EDISCACT, exposed as OData. Reading the table directly gives you the log row but not the document state, and the two disagree often enough to matter.

Payload — from SXMB_MONI?

No. SXMB_MONI is PI/PO middleware and is not reachable from BTP without opening it up. The payload shown is rebuilt from SPROXHDR plus the proxy payload table, which is where the ABAP proxy already persists it. Same content, no new exposure.

What does HOLD mean?

The message is parked from the automatic retry sweep. It stays visible and counts towards the failed total, but nothing retries it until someone releases the hold. It is for a message under investigation, so an auto-retry does not destroy the evidence or repeat a bad command.

Inflight / Failed / Confirmed / SLA breached / Oldest open

Inflight — sent or acknowledged, no final response. Failed — a negative response, or a status of 12 or 22. Confirmed — a positive response written back. SLA breached — inflight for longer than the configured age for its process area. Oldest open — the age of the oldest message still not confirmed, which is the number that tells you whether a backlog is draining or growing.

Day limit impact on the R123 event

The day limit caps how many documents the run releases; it does not change the dunning level. Documents beyond the cap are re-dated, so the R123 event fires later for them rather than not at all. Overriding the number does not touch the slot timings — those stay owned by S/4.

1. Watch the stream. Rows arrive live and change status on their own.
2. Click the Failed tile, select a few rows, hit Retrigger.
3. Open Adhoc message, pick the on-demand meter read, and enter a meter ending in an even digit — it switches to a TOU Request because the meter is interval-metered.
4. Adhoc message → Remote Disconnection Request. A disconnection document is created at status 13, variant CUST. Then run a Reconnection against the same meter — it finds that document. Run one against a meter you never disconnected and it is refused.
5. Try a mass disconnection of more than 100 meters. It parks for a second approver instead of sending.
6. Open any disconnection in the drawer and press Cancel disconnection activity. The document closes, the dunning cycle resets, and a service order rolls a truck.
7. Switch the monitor to Documents. Filter to user status 12, select all, Trigger message — each failed disconnection is re-sent. Then filter 26 and Cancel activity — document closed, dunning reset, service order offered because the command is already at the head end.
8. Dunning → the No-Cut grid opens view only. Press Switch role, then Add new. Try a past date, then a date three years out, then leave the reason blank.
9. Select two entries and press Cancel, then History to see them again. Check a cancelled date — it now reads clear.
10. Dunning → Preview. The blocked list names the No-Cut day and the weather-locked county separately. Set the run date to a day with an All No-Cut and nothing is eligible.
11. Set a manual lock in the banner. Release is disabled everywhere until you clear it.
12. Status reconciliation → Check list. Then resolve an 88 and watch the replication request appear in the monitor.
13. Test harness → pick the TOU Request, edit a bucket, send. Then set the outcome to Timeout and watch that message sit in flight until it breaches its SLA.

Live push over WebSocket instead of the simulated timer, XSUAA roles, the S/4 gateway that raises the actual proxy, HANA persistence, the background sweep that ages messages and raises alerts, and real reads against MDMS staged data (the MDMS staging table) and the head end for the reconciliation.