17 Using Guaranteed Z Events
This chapter contains the following topics:
This chapter provides overviews of Z events, the Z event process, and vendor-specific outbound functions, and discusses how to work with Z events.
17.1 Understanding Guaranteed Z Events
A Z event is near real-time notification that an interoperability transaction has occurred. To generate Z events, JD Edwards EnterpriseOne uses the Z event generator and the existing interface table infrastructure. You can use the existing JD Edwards EnterpriseOne interface tables, or you can build customized interface tables as long as the tables are created using JD Edwards EnterpriseOne standards.
17.2 Z Event Process Flow
This diagram shows Z event processing. The diagram expands on the system diagram provided in the Using Events - Guaranteed Overview chapter. This diagram details the processing that the CallObject kernel does during Z event processing. In the System Overview diagram, the BSFN uses the Event API, all within the CallObject kernel and in turn places the event data into the F90710 table. For Z events, additional processing occurs within the CallObject kernel before the event is placed into the F90701 table. Z events that are placed in the F90710 table are already in XML format (unlike real-time and XAPI events, which only have raw event data in the table).
In summary:
-
When a JD Edwards EnterpriseOne transaction occurs, the master business function writes the transaction information in the appropriate interface table and sends an update record to the F986113 table.
-
A batch process monitors the F986113 table. When the batch process finds a W status in the F986113 table, it notifies the Z Event Generator (ZEVG), which is part of the CallObject kernel. The batch process looks in the F0047 table to determine which Z-event generator to call.
-
The F47002 table provides a cross-reference between the transaction and the interface table where the record is stored. This information is used by the Z-event generator.
-
The Z-event generator retrieves the transaction information from the interface table and converts the transaction information into an XML document using a JD Edwards EnterpriseOne DTD.
-
The Z-event generator sends the event (in the form of an XML document) to the event API for distribution.
-
After an event is successfully generated, the successfully generated column in the F0046 table is updated. A UBE purges information in the interface table based on information in the F0046 table.
-
The Event API sends the XML document to the F90710 table, where it is retrieved by the Transaction server and routed to a subscriber.
17.3 Vendor-Specific Outbound Functions
The purpose of the vendor-specific outbound function is to pass the key fields for a record in the outbound interface tables to a third-party system. With these keys, you can process information from the database record into your third-party system. The generic outbound subsystem batch process calls the function.
Each vendor-specific function is specific to the transaction being processed. You must decide how the function actually uses the database record information. Although the functions are written to your specifications, and most likely are written outside of JD Edwards EnterpriseOne, these functions must use the required JD Edwards EnterpriseOne defined data structure:
| Data Item | Required | I/O | Description |
|---|---|---|---|
| szUserId | Y | I | User ID - 11 characters |
| szBatchNumber | Y | I | Batch Number - 16 characters |
| szTransactionNumber | Y | I | Transaction Number - 23 characters |
| mnLineNumber | Y | I | Line Number - double |
| szTransactionType | Y | I | Transaction Type - 9 characters |
| szDocumentType | Y | I | Document Type - 3 characters |
| mnSequenceNumber | Y | I | Sequence Number - double |
17.4 Working With Z Events
This section provides an overview about Z event configuration and discusses how to add a data export control record.
17.4.1 Configuring Z Events
To generate Z events, complete these tasks:
-
Enable the Z event.
-
Update the Flat File Cross-Reference table.
-
Update the Processing Log table.
-
Verify the subsystem job is running.
-
Purge data fro the interface table.
-
Synchronize F47002 records with F90701 records.
-
Set up data export controls.
17.4.2 Enabling Z Event Processing
You can enable or disable master business functions to write transaction information into interface tables and the F986113 table when a transaction occurs. All outbound master business functions that have the ability to create interoperability transactions have processing options that control how the transaction is written. On the Processing Options Interop tab, the first processing option is the transaction type for the interoperability transaction. If you leave this processing option blank, the system does not perform outbound interoperability processing. The second processing option controls whether the before image is written for a change transaction. If this processing option is set to 1, before and after images of the transaction are written to the interface table. If this processing option is not set, then only an after image is written to the interface table.
17.4.3 Updating Flat File Cross-Reference
When you enable Z events, you also update the F47002 table.The transaction type that you entered in the processing option maps to the F47002 table to determine in which interface tables to store the information from the transaction. You use the Flat File Cross-Reference program (P47002) to update the F47002 table.
17.4.4 Updating the Processing Log Table
The Z event generator uses the F0046 table. The F0046 table contains the keys to the interoperability transaction along with a successfully processed column. The sequence number, transaction type, order type, function name, and function library are obtained from the F0047 table. A vendor-specific record is sequentially created in the F0046 table for every transaction processed by the Interoperability Generic Outbound Subsystem (R00460) UBE or the Interoperability Generic Outbound Scheduler UBE (R00461). For example, if three vendors have subscribed to a transaction using the F0047 table, three records are created in the F0046 table, one record for each transaction. If the vendor-specific object successfully processed the transaction, the Processing Log record is updated with a Y in the successfully processed column. You can use the Processing Log (P0046) program to determine whether a vendor-specific object processed the interoperability transaction correctly.
A purging UBE that purges the interfaces tables runs based on information in the processing log table.
Data in the Processing Log table cannot be changed.
17.4.5 Verifying that the Subsystem Job is Running
When the application master business function adds a record to the F986113 table, a subsystem job is started. Subsystem jobs are continuous jobs that process records from the Subsystem Job Master table. You should verify that the subsystem job is running.
Note:
After the records are processed, instead of ending the job, subsystem jobs look for new data in the data queue. Subsystem jobs run until you terminate them.You can schedule subsystem jobs.
17.4.6 Purging Data from the Interface Table
After you receive the Z event, you should purge the data from the interface table. You can enter a purge UBE in the Processing Log table to purge the interface table.
17.4.7 Synchronizing F47002 Records with F90701 Records
Z events that are automatically created write records to the F90701 table. If you have existing Z events defined and are upgrading your system, you can run the Populate Event Activation Status Table UBE (R90705)to create the associated F90701 table records for the pre-existing Z event definitions.
17.5 Setting Up Data Export Controls
This section provides an overview of setting up data export controls and discusses setting up the record.
17.5.1 Understanding Data Export Controls Records
The generation of outbound data is controlled through the F0047 table. You use the Data Export Controls program (P0047) to update the F0047 table. For each transaction type and order type, you must designate the Z event generator that will process the outbound data. To send a given transaction type to more than one third-party application, you associate the transaction type with each of the individual destinations by making separate entries in the F0047 table for each destination. JD Edwards suggests that you specify the name of a third-party function that is called for each transaction as it occurs. Enough information is provided to notify you of the transaction and give you the key values so that you can retrieve the transaction.
17.5.2 Forms Used to Add a Data Export Controls Record
| Form Name | FormID | Navigation | Usage |
|---|---|---|---|
| Work with Data Export Controls | W0047A | From an application that supports event generation, open the Data Export Controls program
An alternate way to access the Data Export Controls Program is to enter P0047 in the Fast Path command line |
View existing data export control records. |
| Data Export Control Revisions | W0047C | On Work with Data Export Controls, click Add. | Add a new data export control record. |
17.5.3 Adding a Data Export Control Record
Access the Data Export Control Revisions form.
To set up Data Export Controls:
-
Complete these fields:
-
Transaction
-
Order Type
-
-
For each detail row, enter one of these, depending on your platform:
-
Function Name
Windows: _CallOnUpdate@36
UNIX: CallOnUpdate
IBM i: CallOnUpdate
-
Function Library
Windows: EnterpriseOne Bin32 Path\zevg.dll
IBM i: EnterpriseOne Bin32 Path\ZEVG
-
Enter 1 in the Execute For Add column to generate an event for an add or insert.
Complete the same process as appropriate for update, delete, and inquiry.
-
Enter 1 in the Launch Immediately column to launch the object from the Outbound Subsystem batch process.
This column does not affect the Outbound Scheduler batch process.
The system automatically increments the Sequence field for each line.
-