Assignment 3 uses one sync push. Many live services chain several async pushes: the application goes to one partner, waits for its callback, goes to the next partner, and so on. You will not build these in this course (that is Course 2), but you will be asked "where is this application and why is it not moving?". This lesson teaches you to answer.
Events in an async chain
| Transition | Fired by | What it does |
|---|---|---|
INITIATE_PUSH |
The system (systemAuthorised), usually as the nextEvent of the previous state | Runs the breaking INTEGRATION with async: true and moves to a waiting state such as PENDING_PUSH_STEP_1. nextEvent is empty: the application now waits |
PUSH |
The partner's callback (through the integration engine) | Moves from the waiting state to the next state. Its nextEvent is usually INITIATE_PUSH, which starts the next partner |
PUSH_CALLBACK |
The partner, to acknowledge receipt | A separate event, forwarded by the integration engine when the partner acknowledges receipt of a pushed application. Read it like PUSH: it needs its own transition from the waiting state |
REQUEST_FOR_ACTION by a partner |
A partner role on the transition | The partner asks the applicant to correct something. SUBMIT_RFA then returns to the first state of the chain, not to the partner's state, and an IS_RESUBMITTED condition can skip steps that must not repeat |
A two-partner chain, as you will meet it in real services (illustrative state names)
| # | State | Who moves it next | With which event |
|---|---|---|---|
| 1 | PAID |
The system, at once (nextEvent) | INITIATE_PUSH: breaking INTEGRATION to the land registry, async |
| 2 | PENDING_REGISTRY_PUSH |
The registry, when it calls back | PUSH (the callback), with nextEvent INITIATE_PUSH |
| 3 | REGISTRY_DONE |
The system, at once | INITIATE_PUSH: breaking INTEGRATION to the tax office, async |
| 4 | PENDING_TAX_PUSH |
The tax office, when it calls back | PUSH, or REQUEST_FOR_ACTION from the partner |
| 5 | PENDING_RESUBMISSION_PARTNER |
The applicant | SUBMIT_RFA: back to the first state of the chain, so every push runs again with the corrected data |
practice: where is it, who moves it?
For each state in the table above, say out loud who must act next and what you would search in Kibana. Then answer: an application has been in
PENDING_TAX_PUSHfor two days. Who do you contact? (The integration manager, with the application number: they open the call in Requests and check the callback status.)
Reading a stuck async application
| Symptom | What it means | Who can move it |
|---|---|---|
Stuck in a state just before a push (for example PAID) |
INITIATE_PUSH failed: the breaking INTEGRATION was refused or the partner was down. The engine retried, then recorded it in PROCESSING_FAILURE_TRACKER | Support re-triggers the event once the cause is fixed (lesson D6) |
Stuck in a PENDING_..._PUSH waiting state |
The request left; the callback never came | The integration manager checks the callback status in Requests and asks the partner, or resubmits the call |
| Callback arrived but the state did not change | No PUSH transition from that waiting state, or the callback named another event | You: fix the workflow with a Service Improvement |
| Back at the first push state | A partner requested an action and the applicant resubmitted: the chain runs again | Normal; check IS_RESUBMITTED branches if a push should not repeat |
Kibana: two searches for an async application
| When | KQL (paste in Discover) | What you get |
|---|---|---|
| Did the push leave? | message:"Async Integration Request:" and message:"<APP_NO>" |
The request and its callback URL |
| Did the system event fail? | message:"PROCESSING_FAILURE_TRACKER" and message:"<APP_NO>" |
The failed event (INITIATE_PUSH, PAY...), its start state and the error |
Gotcha · the applicant sees nothing of this
While the application waits for partners, the applicant sees the state name you gave it ("Submitted for Processing" if you reused the label). Give waiting states clear names, and set the expected processing time from the slowest partner.
Tip · reference
INTEGRATION action · Events · Course 2: Integration Manager Certification.
In an async chain, which event moves an application out of its waiting PENDING_..._PUSH state?
D. INITIATE_PUSH sends the request and the application waits. Only the partner's callback (PUSH) moves it on. No callback, no movement.
← C3 · Push from the workflow · C4 · Assignment 3: CanalBox subscription renewal →