D Using Classic Z Events

This appendix contains the following topics:


This chapter is applicable only if you use classic events delivery. Classic event delivery is available when 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.

Refer to the Guaranteed Events chapters if 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 and later Applications releases.

D.1 Understanding Z Events - Classic

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.

Z event XML documents use the JD Edwards EnterpriseOne XML Response format. An example of the Z event XML document can be found in Appendix E, XML Format Examples (Events). Different events can have different table names and column names.

D.1.1 Prerequisites

Before you complete the tasks in this section:

  • You must enable security for the JD Edwards EnterpriseOne server.

  • You must have a valid security record for the default user under the [SECURITY] section of the JD Edwards EnterpriseOne server jde.ini file (that is, the user must be a valid JD Edwards EnterpriseOne user).

D.2 Z Event Process Flow

This diagram depicts a logical representation of the processes and data for Z event generation:

Figure D-1 Z event process flow

Description of Figure D-1 follows
Description of "Figure D-1 Z event process flow"

In summary:

  1. 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.

  2. 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. The batch process accesses the F0047 table to determine which Z-event generator to call.

  3. 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.

  4. 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.

  5. The Z-event generator sends the event (in the form of an XML document) to the event notification kernel for distribution.

  6. After an event is successfully generated, the system updates the F0046 table.

    A UBE purges information in the interface table based on information in the Processing Log table.

  7. The event notification kernel sends the XML document to all subscribers.


    If you use IBM WebSphere MQ or MSMQ transports, the transport driver writes system and function errors to the JDE error log. The driver writes error messages and adds the error codes, if available.

D.3 Z Event Sequencing

When you define your Z events, you indicate whether the event is reliable or volatile. If you define the event as volatile, the system automatically provides event sequencing to guarantee that events are delivered in the correct order. Volatile events are stamped using features of JD Edwards EnterpriseOne Next Numbers.

For sequencing of Z events, ZEVG, the Z event generator, retrieves the next number from the Z event sequencing bucket and sends the number to the EVN kernel for sequencing purposes. It is important to note that JD Edwards only guarantees the sequence for the particular type of event generator. This is due to the inherent delays that are involved in the Z event processing; an event that occurred earlier can get a later sequence number.

Event sequencing does affect performance. You can clear events sequencing. You can also define a timeout value to tell the system to stop looking for a missed event when events are out of sequence. The flag and timeout settings are in the [INTEROPERABILITY] section of the jde.ini file.

D.4 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 as illustrated in this table:

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

D.5 Working With Z Events

This section provides an overview of Z event processing and discusses how to set up a data export control record.

D.5.1 Understanding Z Event Processing

To use Z events to retrieve information from JD Edwards EnterpriseOne, perform these tasks:

  • Enable Z event processing.

  • Update Flat File Cross-Reference table.

  • Update the Processing Log table.

  • Verify that the subsystem job is running.

  • Purge data from the interface table.

  • Configure the jde.ini file for Z events.

  • Set up data export controls.

D.5.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, the system writes before and after images of the transaction to the interface table. If this processing option is not set, then the system writes only an after image to the interface table.

See Interoperability Interface Table Information.

D.5.3 Updating Flat File Cross-Reference 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 which interface tables to use to retrieve the information. You use the Flat File Cross-Reference program (P47002) to update the F47002 table.

D.5.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 that is 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, the system creates three records 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 correctly processed the interoperability transaction.

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.

D.5.5 Verifying that the Subsystem Job is Running

When the application master business function adds a record to the F986113 table, the system starts a subsystem job. Subsystem jobs are continuous jobs that process records from the F986113 table. You should verify that the subsystem job is running.


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.

See "Understanding JD Edwards EnterpriseOne Subsystems" in the JD Edwards EnterpriseOne Tools System Administration Guide.

See "Understanding the Job Scheduler" in the JD Edwards EnterpriseOne Tools System Administration Guide.

D.5.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 F0046 table to purge the interface table.

See Purging Interface Table Information.

See Interoperability Interface Table Information.

D.5.7 Configuring the jde.ini File for Z Events

To generate Z events, you must configure these sections of the JD Edwards EnterpriseOne server jde.ini file:



  • [JDENET]


The settings for the EVN kernel, [JDEITDRV], and [JDENET] are defined in the jde.ini File Configurations for Events section of this guide. You must configure settings for [INTEROPERABILITY].


Configure these settings:


The SequenceTimeOut setting is for sequencing of volatile events. The value is in seconds.

Null strings and zeros are trimmed off Z events. You can clear this feature by entering a value of 0 (zero) for the XMLElementSkipNullOrZero setting.

D.6 Setting Up Data Export Controls

This section provides an overview of setting up data export controls and discusses how to set up the record.

D.6.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 processes 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 for each destination in the F0047 table. 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.

D.6.2 Forms Used to Add a Data Export Controls Record

Form Name FormID Navigation Usage
Work with Data Export Controls W0047A From a application that supports event generation, open the Data Export Controls Program

An alternative 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.

D.6.3 Adding a Data Export Control Record

Access the Data Export Control Revisions form.

To set up Data Export Controls:

  1. Complete these fields:

    • Transaction

    • Order Type

  2. For each detail row, enter one of these, depending on your platform:

    • Function Name

      Windows NT: _CallOnUpdate@36

      UNIX: CallOnUpdate

      IBM i: CallOnUpdate

    • Function Library

      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/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.