Understanding Guaranteed Events Processing

This diagram provides an overview of the JD Edwards EnterpriseOne events architecture:

In summary, this is the general sequence that happens for an event to be published:

1. An HTML client user executes a business function request that is sent to the JD Edwards EnterpriseOne Web server.

2. The request is forwarded to a CallObject kernel on the JD Edwards EnterpriseOne server.

3. The CallObject kernel executes the business function, which calls the Event API to send the event data to the F90710 table.

   If the event is a Z event, the data sent to the F90710 table is in its final XML format.

4. A trigger message is sent to the JD Edwards EnterpriseOne Transaction server that indicates that a new event is in the F90710 table.

5. The transaction server retrieves the event data from the F90710 table and, for real-time and XAPI events, converts the event data to an XML document in the appropriate format.

6. The transaction server routes the event to the subscriber queues and subscriber topics for each subscriber that has established an active subscription for that event.

7. When a subscriber connects to the transaction server, the subscriber receives all the events that exist in its subscription queue and subscription topic at that time.

Note: XAPI and Z events require additional information for event processing, which is discussed in the respective XAPI and Z event chapters.