11 Processing Z Transactions

This chapter contains the following topics:

11.1 Understanding Z Transactions

Z transactions are non-JD Edwards EnterpriseOne information that is properly formatted in the interface tables (Z tables) for updating to the JD Edwards EnterpriseOne database. Interface tables are working tables that mirror JD Edwards EnterpriseOne applications tables. JD Edwards EnterpriseOne provides predefined interface tables for some application transactions. You also can create your own interface tables as long as they are formatted according to JD Edwards EnterpriseOne standards.

You can process Z transactions into JD Edwards EnterpriseOne one transaction at a time (referred to as a batch of one), or you can place a large number of transactions into the interface table and then process all of the transactions at one time (referred to as a true batch).

See Also:

11.2 Naming the Transaction

Z transaction types are defined in user-defined code 00/TT. If you create a new transaction, you must define the transaction in user-defined code 00/TT. When you name a new transaction type, the name must start with JDE and can be up to eight characters in length. These examples illustrate a proper transaction name:

  • JDERR for Receipt Routing Transaction.

  • JDEWO for Work Order Header Transaction.

11.3 Adding Records to the Inbound Interface Table

When you write your transaction to the appropriate interface table, you make the information available to JD Edwards EnterpriseOne for processing. Z transactions may be written directly to interface tables that are already in the EnterpriseOne database format. This list shows some of the ways that you can add records to the inbound interface tables:

11.4 Running an Update Process

You can process Z transactions in one of these ways:

  • Run an input batch process, which enables you to place a large number of transactions into the interface table and then process all of the transactions as one in batch mode.

  • Run a subsystem job, which enables you to send transactions to JD Edwards EnterpriseOne one at a time without having to wait for completion to continue processing using the subsystem.

JD Edwards EnterpriseOne provides input batch and input subsystem processes for some applications.

11.4.1 Running an Input Batch Process

The input batch process enables you to place one or more records in an interface table and then run a UBE to process all of the records at one time. You initiate the input batch process for an application that supports inbound interoperability processing. When you select the input batch program, the program displays a version list of report features. You can use an existing report version, change an existing report version, or add a report version. You can change the processing options and data selection when you use a report version. The input batch process program generates an audit report that lists the transactions that were processed, totals for the number of processed transactions, and errors that occurred during processing.

11.4.2 Running a Subsystem Job

Subsystem jobs are continuous jobs that process records from a data queue and run until you terminate the job. Subsystem jobs read records one at a time for a subsystem table, retrieve information from that particular record, and run a UBE or table conversion for each record. This triggers the inbound processor batch process that processes that specific key. If required, a preprocessor runs from the inbound processor batch process to establish key information that matches the interface table record to the original application record (for example, the key to a cash receipt or purchase receipt). After processing the last record, instead of ending the job, subsystem jobs wait for a specific period and then attempt to retrieve a new record. For each subsystem job, multiple records can exist in the subsystem table.

You can schedule subsystem jobs.

You initiate a subsystem job in one of these ways:

Ways to Initiate Subsystem Jobs Explanation
Use a business function You can use the generic subsystem business function, Add Inbound Transaction to Subsystem Queue (B0000175), for inbound transactions. This function writes a record to the F986113 table to specify a batch process that needs to be awakened in the subsystem. The business function also passes keys to the subsystem data queue. The business function then starts processing the transaction.
Use the Solution Explorer You can use the Solution Explorer to initiate the input subsystem batch process for an application that supports inbound interoperability processing. You start the subsystem job as you would a regular batch job. Unlike other batch jobs, subsystem jobs can only run on a server. Before processing, JD Edwards EnterpriseOne makes sure that limits for the subsystem job on the particular server have not been exceeded. If limits have been exceeded, the subsystem job will not be processed. To process your Z transaction in near real-time mode, start the subsystem when you start your system. You will need to place your request in the data queue before you write your transaction to the interface table.

Important:

Instead of ending the job after the records have been processed, subsystem jobs look for new data in the data queue. Subsystem jobs run until you terminate them.

See Also:

11.5 Checking for Errors

The input batch process uses the data in the interface tables to update the appropriate JD Edwards EnterpriseOne application tables as dictated by the business logic. If the process encounters an error for the transaction, the record is flagged in the processor audit trail report and error messages are sent to the employee work center in the form of action messages. These action messages, when invoked, call a revision application that enables you to make corrections to the interface table.

When you review the errors in the work center, you can link directly to the associated transaction in the interface table to make corrections. You use a revision application to resubmit individual corrected transactions for immediate processing, or you can correct all transaction errors and then resubmit them all at once in a batch process.

The system flags all transactions that have been successfully updated to the live files as successfully processed in the interface tables.

See Also:

11.6 Confirming the Update

This step is optional. If you use a business function, you can create a confirmation function to alert you that a transaction you sent into the JD Edwards EnterpriseOne system has processed. When processing is complete, JD Edwards EnterpriseOne calls the function that is specified in the request to notify you of the status of your process. The confirmation functions are written to your specifications, but you must use the JD Edwards EnterpriseOne defined data structure. Interoperability inbound confirmation functions are called from the inbound processor batch program through the Call Vendor-Specific Function - Inbound business function.

The confirmation function is specific to a process and must accept these parameters:

User ID 11 characters
Batch Number 16 characters
Transaction Number 23 characters
Line Number Double
Successfully Processed 1 characters

The first four parameters are the keys (EDUS, EDBT, EDTN, EDLN) to the processed transaction. The last full path of the library containing the function must be passed to the subsystem batch process that processes the transaction. This information is passed through the inbound transaction subsystem data structure.

After the subsystem batch process finishes processing the transaction, it calls the inbound confirmation function, passing the keys to the processed transaction and the notification about whether the transaction was successfully processed. You include logic in your function to take appropriate action based on the success or failure of the transaction.

If you create a transaction confirmation function, you can also use the function to perform any of these tasks:

Task Explanation
Update your original transaction By creating a cross-reference between the original transaction and the transaction written to the interoperability table, you can access the original transaction and update it as completed or at an error status.

Using the key returned to this function, you can access the transaction that is written to the interoperability interface table and retrieve any calculated or default information to update your original transaction.
Run other non-JD Edwards EnterpriseOne business processes If your transaction is complete, you might want to run a business process that completes the transaction in the non-JD Edwards EnterpriseOne software.
Send messages to users You might want to inform your users of the status of their original transactions.

11.7 Purging Data from the Interface Table

You should periodically purge records that have been successfully updated to the JD Edwards EnterpriseOne database from the interface tables.

See Also: