EI or EO

[Barnali Goswami]

There is an application say Application A, which accepts orders from two channels: B2B interface and GUI.

Flow of order in B2B
1. It receives an order from upstream, validates, enriches it and places the order in another application downstream. In the process, it also logs the details of the order (things like order id, status etc, not all parameters) for audit trail and trouble shooting. The entire flow is a synchronous activity.

Flow of order in GUI channel
2. The user uses it to reinitiate a failed order or create a new order. The flow is similar, it logs details required for tracking and places the order on some other application downstream. The user who places the order is aware that the order is not placed in this application but downstream.

Response Flow.
3. Once the order is placed downstream, the downstream application sends a response. Application A updates the order status on receiving the response. It checks whether the order has been placed from the GUI or the B2B channel. If its the latter, the response is sent to the application which initiated the order. If the channel is GUI, the details are stored internally and not propagated further. User can see this response on a web page if required.

Can you help me accounting process 1, 2 and the response? I strongly feel that both 1 and 2 are EOs as the primary intent is not to update Application A but send the details downstream. Response can be broken down to an EO and an EI but if I consider the channel check as a part of a decision tree for the entire flow, the response again is an EO as a whole.

I would love to have your thoughts on this one.

[Frank Vogelezang]

Barnali,

The elementary process 1 (B2B) is to place an order in an application downstream. In order to do so it receives the incoming order from upstream, reads data from application A to enrich the order and stores audit and troubleshooting data, and sends the enriched order downstream. This whole process is elementary and is an EO.

Same for process 2 (GUI). The elementary process is to send an order downstream, which is an EO.

I guess the response processing contains two elementary processes: The update of the order status, which includes internal storage of the details in case of a GUI order, is counted as an EI. In case of a B2B order the response is propagated upstream to the application that placed the order.

[Ian Alyss]

Arr you sure? Is logging the details included in the EO? Why not a separate EI?

[Jacqueline Eshuis]

Hi Ian,

yes, we are very sure about logging the details is included in the EO. An EO can update a file.

In this case, it is not possible to split the EI from the EO when receiving the data from the B2B or the GUI. In itself, logging the data is of no interest to the user, if the EO part, sending the data to the downstream application, has not been done.

The response from the downstream is registered and for the GUI, that’s it. So there is no EO involved, only the EI. The B2B response will be another EO.

[Author]

Posts