|JD Edwards EnterpriseOne Tools Interoperability Guide
Release 8.98 Update 4
Part Number E14711-02
|PDF · Mobi · ePub|
This chapter contains the following topics:
Note:This chapter is applicable only if you use guaranteed events delivery. Guaranteed event delivery is available when you use JD Edwards EnterpriseOne Tools 8.94 with JD Edwards EnterpriseOne Applications 8.11 or JD Edwards EnterpriseOne Tools 8.95 and later tools releases with JD Edwards EnterpriseOne Applications 8.10, 8.11, and later EnterpriseOne Applications releases.
Refer to the Classic Events chapters if you use JD Edwards EnterpriseOne Tools 8.93 or earlier releases, or if you use JD Edwards EnterpriseOne Tools 8.94 with JD Edwards EnterpriseOne Applications 8.10.
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.
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).
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.
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:
|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|
This section provides an overview about Z event configuration and discusses how to add a data export control record.
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.
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.
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.
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.
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.
Z events that are automatically created write records to the F90701 table. If you have existing Z events defined and are upgrading to an 8.11 or later release, 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.
This section provides an overview of setting up data export controls and discusses setting up the record.
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.
|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.|
Access the Data Export Control Revisions form.
To set up Data Export Controls:
Complete these fields:
For each detail row, enter one of these, depending on your platform:
Windows NT: _CallOnUpdate@36
IBM i: CallOnUpdate
Windows NT: EnterpriseOne Bin32 Path\zevg.dll
UNIX(HP): EnterpriseOne Bin32 Path\libzevg.sl
UNIX(AIX, SUN): EnterpriseOne Bin32 Path\libzevg.so
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.