A Classic Events

This appendix contains the following topics:

• Section A.1, "Understanding Classic Events"

• Section A.2, "Defining Events"

• Section A.3, "Subscribing to Events"

• Section A.4, "Configuring the jde.ini file for Events"

• Section A.5, "Using Reliable Event Delivery"

• Section A.6, "Entering Events"

• Section A.7, "Adding Logical Subscriber Records"

• Section A.8, "Entering Subscription Information"

Note:

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.

A.1 Understanding Classic Events

JD Edwards event functionality provides an infrastructure that can capture JD Edwards EnterpriseOne transactions in various ways and provide real-time notification to third-party software, end users, and other JD Edwards systems, such as WSG and CRM.

JD Edwards EnterpriseOne notifications are called events. The JD Edwards EnterpriseOne event system implements a publish/subscribe model. Events are delivered to subscribers in XML documents that contain detailed information about the event. For example, when you enter a sales order into the system, the system can automatically send the sales order information to a CRM or supply chain management application for further processing. If your system is IBM, you can use IBM WebSphere MQ messaging to receive events. If your system is Microsoft, you can use MSMQ messaging to receive events. IBM WebSphere MQ and MSMQ provide a point-to-point interface with JD Edwards EnterpriseOne. JD Edwards EnterpriseOne supports three kinds of events, as described in the table:

Type of Event	Description
Z Events	A service that uses interface table functionality to capture JD Edwards EnterpriseOne transactions and provide notification to third-party software, end-users, and other JD Edwards systems that have requested to be notified when certain transactions occur.
Real-Time Events	A service that uses system calls to capture JD Edwards EnterpriseOne transactions as they occur and provide notification to third-party software, end users, and other JD Edwards systems that have requested notification when certain transactions occur.
XAPI Events	A service that uses system calls to capture JD Edwards EnterpriseOne transactions as they occur and then calls third-party software, end users, and other JD Edwards systems that have requested notification when the specified transactions occur to return a response. XAPI events can be from JD Edwards EnterpriseOne to a third-party system, from a third-party system to JD Edwards EnterpriseOne, or between two JD Edwards EnterpriseOne systems.

The JD Edwards EnterpriseOne event system consists of these modules:

• Event distributor

• Event generators

• Transport drivers

The event distributor is a JD Edwards EnterpriseOne kernel process called the event notification (EVN) kernel. The EVN kernel manages the subscribers and notifies them when an event occurs. The EVN kernel is shared by Z events, real-time events, and XAPI events.

Event generators are processes or libraries capable of generating events. JD Edwards EnterpriseOne provides three default event generators:

• Z event generator, which generates Z events.

• Real-time event generator, which generates real-time events.

• XAPI event generator, which generates XAPI events.

Z events, real-time events, and XAPI events have slightly different XML documents.

The event distributor uses a transport driver to send events. JD Edwards EnterpriseOne provides a default transport driver that uses JDENET. The event distributor can also send event documents to designated IBM WebSphere MQ or MSMQ outbound queues using IBM WebSphere MQ or MSMQ transport drivers. If you use IBM WebSphere MQ or MSMQ transport drivers to receive events, you receive all events that are defined in the F90701 table.

A.2 Defining Events

When an event is generated, the IEO kernel reads the F90701 table for that event. If the specified event category is different from the event category configured in the database, the system writes an error to the IEO log file. If the database definition of the event is not found, the system writes this message to the IEO log.

Warning: table F90701 doesn't exist. Some features will be turned off.

Note:

When you update or modify the F90701 table, you must restart the server for the changes to become effective.

A.2.1 Reducing Network Traffic

To reduce network traffic, real-time event processing sends only active events. If a single event is identified as inactive in table F90701 and is part of an active container event, the CallObject kernel sends the active container event and the active single events to the IEO and EVN kernels to create the XML and to distribute to subscribers. Inactive single events that have been disabled by the CallObject kernel are embedded in the container event but are not sent as separate single events.

The CallObject kernel debug log contains information about the inactive single events that are not created. This is an example CallObject Kernel debug log message:

Inactive container event <event name> is not added to prevent bursting

This scenario illustrates the process:

• RTABHDR and RTABPHOUT are inactive single events.

• RTABEAOUT is an active single event.

• RTABOUT is an active container event that contains RTABHDR, RTABPHOUT, and RTABEAOUT.

• The business function creates these events:

  • 1 RTABHDR event

  • 2 RTABPHOUT events

  • 5 RTABEAOUT events

• The RTABOUT container event and the five RTABEAOUT events are sent from the CallObject kernel to the IEO and EVN kernels for processing and distribution to the subscriber. Inactive single events, RTABHDR and RTABPHOUT, are not sent.

• The subscriber receives:

  • 1 RTABOUT container event with all of the subdata structures that are defined in the single events RTABHDR, RTABPHOUT, and RTABEAOUT.

  • 5 RTABEAOUT single events.

A.3 Subscribing to Events

For XAPI events, you must update the F90702 table so that you can receive a response to your XAPI event. Each XAPI event must have a logical subscriber, which you might have to set up. For Z and real-time events, the system dynamically updates this table when the event is created. You can use the F90702 table to view the persistent subscriptions for your Z and real-time events.

If the database table is missing, the system writes these messages to the IEO log:

CheckTableExists failed: invalid hEnv or hUser.

Warning: table F90702 doesn't exist. Some features will be turned off.

A.4 Configuring the jde.ini file for Events

The JD Edwards EnterpriseOne server jde.ini file must be properly configured to support Z, real-time, and XAPI event generation. You use a text editor to manually edit and verify specific settings in the JD Edwards EnterpriseOne server jde.ini file.

Note:

If your enterprise contains more than one JD Edwards EnterpriseOne server, you must ensure that each server has the same settings for all logic, batch, and interoperability sections.

Use these kernel and [JDEITDRV] settings to configure the jde.ini file on your JD Edwards EnterpriseOne server. Configure the kernels that are appropriate for the type of event (Z, real-time, or XAPI) that you want to generate.

Note:

To determine which kernels you need to set and for other jde.ini settings for each specific type of event, refer to the Configure the jde.ini File topics in the Events section of the Interoperability Guide.

A.4.1 [JDENET_KERNEL_DEF19]

Use these settings for a Windows Microsoft platform:

krnlName=EVN KERNEL
dispatchDLLName=jdeie.dll
dispatchDLLFunction=_JDEK_DispatchITMessage@28
maxNumberOfProcesses=2
numberOfAutoStartProcesses=2

A.4.2 [JDENET_KERNEL_DEF20]

Use these settings for a Microsoft Windows platform:

krnlName=IEO KERNEL
dispatchDLLName=jdeieo.dll
dispatchDLLFunction=_JDEK_DispatchIEOMessage@28
maxNumberOfProcesses=2
numberOfAutoStartProcesses=2

Important:

If you use JD Edwards EnterpriseOne 8.10 or a release prior to JD Edwards EnterpriseOne 8.10, the maxNumberOfProcesses and the numberOfAutoStartProcesses settings for both the EVN kernel (JDENET_KERNEL_DEF19) and the IEO kernel (JDENET_KERNEL_DE20) should have the same value. For example, maxNumberOfProcesses=3 and numberOfAutoStartProcesses=3. This causes the processes to be automatically started and avoids the cyclic dependency of the three-way request message from the IEO to the EVN kernel with the Get Event List message from the EVN to the IEO kernel.

A.4.3 [JDENET_KERNEL_DEF22]

Use these settings for a Microsoft Windows platform:

krnlName=XML Dispatch KERNEL
dispatchDLLName=xmldispatch.dll
dispatchDLLFunction=_XMLDispatch@28
maxNumberOfProcesses=1
numberOfAutoStartProcesses=0

A.4.4 [JDENET_KERNEL_DEF24]

Use these settings for a Microsoft Windows platform:

krnlName=XML Service KERNEL
dispatchDLLName=xmlservice.dll
dispatchDLLFunction=_XMLServiceDispatch@28
maxNumberOfProcesses=1
numberOfAutoStartProcesses=0

A.4.5 [JDEITDRV]

Use these settings for a Microsoft Windows platform:

DrvCount=5
Drv1=Z:zdrv.dll
Drv2=RT:rtdrv.dll
Drv3=JDENET:jdetrdrv.dll
Drv4=MSMQ:msmqrtdrv.dll
Drv5=MQS:mqsrtdrv.dll

Note:

You set event generation and transport drivers in the [JDEITDRV] section of the jde.ini file. You are not required to set all of these drives. For example, if you do not use messaging transports, you would not use the MSMQ and MQS settings. Be sure that you define DrvCount with the number of settings that you are using.

A.4.6 [JDENET]

This setting specifies the maximum number of JDENET kernels:

MaxKernelRanges=27

Note:

You must set this value to encompass the total number of kernels that you defined.

This table shows the DLL and DRV settings for other platforms:

Table Column Heading	IBM i	HP9000	Sun or RS6000
EVN (19) dispatchDLLName	JDEIE	libjdeie.sl	libjdeie.so
EVN (19) dispatchDLLFunction	JDEK_DispatchITMessage	JDEK_DispatchITMessage	JDEK_DispatchITMessage
IEO (20) dispatchDLLName	JDEIEO	libjdeieo.sl	libjdeieo.so
IEO (20) dispatchDLLFunction	JDEK_DispatchIEOMessage	JDEK_DispatchIEOMessage	JDEK_DispatchIEOMessage
XML Dispatch (22) dispatchDLLName	XMLDSPATCH	libxmldispatch.sl	libxmldispatch.so
XML Dispatch (22) dispatchDLLFunction	?XMLDispatch?	?XMLDispatch?	?XMLDispatch?
XML Service (24) dispatchDLLName	XMLSERVICE	libxmlservice.sl	libxmlservice.so
XML Service (24) dispatchDLLFunction	JDEK_XMLServiceDispatch	JDEK_XMLServiceDispatch	JDEK_XMLServiceDispatch
Drv1	RTDRV	librtdrv.sl	librtdrv.so
Drv2	ZDRV	libzdrv.sl	libzdrv.so
Drv3	JDETRDRV	libjdetrdrv.sl	libjdstrdrv.so
Drv4	MSMQRTDRV	libmsmqrtdrv.sl	libmsmqrtdrv.so
Drv5	MQSRTDRV	libmqsrtdrv.sl	libmqsrtdrv.so

A.5 Using Reliable Event Delivery

This section provides an overview of reliable event delivery and discusses:

• Configuration of the reliable event delivery system.

• Use reliable event error messages.

• Minimize duplicate and lost events.

• Increase performance.

• Configuration of the jde.ini file.

A.5.1 Understanding Reliable Event Delivery

Reliable event delivery supports Z events, real-time events, and XAPI events. To use the Reliable Event Delivery feature, you must define your events in database tables. You cannot define your events in the jde.ini file.

The JDENET transport delivers Z events, real-time events, and XAPI events. Reliable event delivery ensures recovery and delivery of an event when transport problems arise, including some network problems. These scenarios identify circumstances for which events might be lost, but can be recovered and delivered:

• The JDENET process is down.

• JDENET fails to deliver because the network link between sender and receiver is permanently down.

• JDENET fails to deliver because the IPC buffer of the receiving kernel is full (sender and receiver are on different boxes).

  Note:

  Reliable delivery covers failures that are related only to the transport of the events. Reliable delivery does not provide a once-and-only-once type of guarantee. Events might be lost and not recovered (or duplicates might be redelivered) in the presence of process failures (client and server).

Real-time event delivery is reliable for transportation failures between the real-time API and the Java connector, which includes IEO and EVN kernels. XAPI outbound event delivery is reliable for transportation failures between the XAPI API and the Java connector, including the IEO and EVN kernels. Z event delivery is reliable for transportation failures between the Z event generator and the Java connector.

The level of reliability is configurable based on whether the event is reliable or volatile. Volatile events are events that might be lost if the network or process fails and delivery is not reliable. Reliable events could be lost in the case of process failures only. You can configure the level of reliability for every event type. The level of reliability depends on whether the event is a business critical event. For example, you might configure an inquiry as volatile, because an inquiry is not a critical business event and you do not want the system to continually look for the event should the event fail. You might configure a purchase order as reliable, because this is a critical business event and you do want the system to continually look for the event and make the transaction update. Volatile events offer better performance than reliable events, but delivery is not reliable if the event is lost during transportation.

Real-time and XAPI events can be single, aggregate, or composite events. A composite event consists of single events. The composite event and the single events that make up the composite event can have different levels of reliability. For example, you register composite events as RTSOOUT with a level of reliability as reliable, and you register single events as RTSOLINE with a level of reliability as volatile. The level of reliability configured for RTSOOUT will not override the level of reliability that is configured for RTSOLINE. The rationale for this is that the reliability of events is based on the event type. If you decide that single event types are not important enough to configure as reliable delivery, then the single events that are created during composite event creation should have the same level of reliability as other single events.

The APIs you use to create real-time and XAPI events are not affected by the level of reliability.

A.5.2 Configuring Your System for Reliable Event Delivery

To use the reliable event delivery feature, you must define your events in the F90701 table. Use the Interoperability Event Definition (P90701) program to accomplish this task. On the Event Entry form, you must set up the Threshold Timeout field and set the Reliable Delivery field to reliable (either Y or 1). The Timeout Threshold field is in seconds and applies only to the reliable events for which an initial delivery attempt fails. This field determines the maximum amount of time that has to pass from the event creation to the time when the event is going to be discarded if not delivered successfully. Events with a threshold of zero never expire.

Two database tables, the F90704 table and the F90703 table, enable communication between the sender and receiver. Event Protocol stores information that is associated with the protocol that delivers an event. Event Link stores information that is associated with the reliable event for which initial delivery failed. These tables are updated by the system when an event is created.

Note:

Both the sender and receiver must access the same instances (the data sources are the same) of the interoperability database tables.

A.5.3 Reliable Event Error Message

If the reliable event is not found, this message might be generated in the client, Callobject, IEO, and EVN logs:

RDEL0000045 - Could not open tables for reliable event delivery (F90703 and F90704). Reliable event delivery will be disabled.

If you receive this error message, verify your events are defined in the F90701 table, that the Reliable Delivery and Threshold Time fields are set up correctly, and that the Event Protocol and Event Link tables exist.

A.5.4 Minimizing Duplicate and Lost Events

The architecture for real-time events processing is changed from a fast request reply (FRR) protocol to a three-way protocol. The three-way protocol enables the storage of event information in the F90703 and F90704 tables. Also, both the Java connector and the COM connector can receive and recover real-time events.

This diagram shows the architecture for real-time event recovery using the three-way protocol:

Figure A-1 Three-way architecture for processing events

Description of "Figure A-1 Three-way architecture for processing events"

If the CallObject kernel is unable to communicate with the IEO kernel, the event API inserts the event information into the F90703 and F90704 tables. The IEO kernel recovers the event information from the tables.

If communication between the IEO and EVN kernels fails, the IEO kernel inserts the information into the F90703 and F90704 tables. The EVN kernel recovers the event information from the F90703 and F90704 tables.

If a communication failure between the EVN kernel and the connector occurs, event information is stored in the F90703 and F90704 tables. Both the Java connector and the COM connector have the ability to recover event information from the F90703 and F90704 tables.

A.5.5 Increasing Performance

To increase performance, the concept of a black list is introduced. The black list is a list of subscribers that are not responding to the event message. The black list concept helps to increase performance by not retransmitting to non-responsive subscribers.

If the EVN kernel cannot send an event to a subscriber, the subscriber is placed on the black list. When a subscriber is placed on the black list, the EVN kernel inserts the event information to the F90703 and F90704 tables until the subscriber is removed from the black list. When the subscriber is removed from the black list, the subscriber receives new event information from the EVN kernel and the connector recovers existing event information from the F90703 and F90704 tables and sends this event information to the subscriber.

Subscribers can be placed on the black list in one of two ways:

• Voluntary

• Forced

A.5.5.1 Voluntary Black List

When a subscriber goes down and sends an unsubscribe message, the EVN kernel adds the subscriber to the black list. No event information is sent to the subscriber until the user re-subscribes. The EVN kernel inserts the event information into the F90703 and F90704 tables, and the information is recovered by the connector once the subscriber re-subscribes. Information about adding and removing the subscriber from the black list can be found in the EVN kernel debug log. These are example EVN kernel debug log messages:

• Added receiver <host name>:<port> to black list.

• Removed receiver <host name>:<port> from black list.

A.5.5.2 Forced Black List

When the EVN kernel sends an event that is defined as reliable to a subscriber, and the subscriber fails to reply to the EVN kernel, the EVN kernel adds that subscriber to the forced black list, and inserts the event information to the F90703 and F90704 tables. Settings that you configure in the jde.ini file determine how many times the EVN kernel sends an event with no response from the subscriber before the subscriber is placed on the black list, and the event information is stored in the database tables. You also configure jde.ini settings that determine how often the system tries to revisit the subscriber to remove that subscriber from the black list.

Information about adding, revisiting, and removing a subscriber can be found in the EVN kernel error log. These are example EVN kernel error log messages:

• Added receiver <host name>:<port> to force black list.

• Revisit receiver <host name>:<port> in force black list.

• Removed receiver <host name>:<port> from force black list.

  More detail information about adding the subscriber to the black list can be found in the EVN kernel debug log. This is an example EVN kernel debug log message: Added receiver <host name>:<port> to forced black list, after 2 retries with 15 seconds of wait time.

A.5.6 Configuring the jde.ini File

For reliable event delivery, you must configure these sections and settings in the jde.ini file. These settings are in addition to the settings discussed in the real-time and XAPI events chapters.

A.5.6.1 [INTEROPERABILITY]

Setting	Typical Value	Purpose
EnableBlacklist=	1	A value of 1 enables black list capabilities. The default value is 0 (zero). If you use a value of 0 and your system breaks, your system performance can be affected.
MaxFailedAllowed=	1	Defines the number of failed attempts that the EVN kernel makes to the subscriber before placing the subscriber on the black list. The default value is 3.
ForceBlackListRevisitTime=	60	Defines how often the EVN kernel will attempt to communicate with the failed subscriber once the subscriber is placed on the black list. The default value is 300 seconds.

A.5.6.2 [NETWORK QUEUE SETTINGS]

Setting	Typical Value	Purpose
JDENETTimeout=	60	Defines the time that the EVN kernel waits for a response. Note: You should have the same number of JDENET processes as EVN kernels.

A.6 Entering Events

This section provides an overview of entering events in the Interoperability Event Definition table and discusses how to enter single and container events.

A.6.1 Understanding Entering Events

You use the Event Request Definition program (P90701) to add new single and container events and to review your existing events. You add single events by event name. When you add a single event, you must include a data structure. A container event contains either single events, aggregate events, or both. When you add a container event, you define events, single events to be used individually, or data structures, single events to be aggregated. You can change the information for single and container events. You can delete single and container events. You can change the status of an event to active or non-active. If your system has multiple environments, the event status is the same in all environments. You can use menu options to access the subscriber information.

Note:

A XAPI event is always a container event, and you must define data structures for XAPI events.

A.6.2 Forms Used to Add Events

Form Name	FormID	Navigation	Usage
Event Definition Workbench	W90701A	Enter P90701 in the Fast Path.	Locate and review existing single and container events.
Event Entry	W90701D	On Event Definition Workbench, click Add.	Add or change a single or container event.
Event Definition Detail	W90701C	Automatically appears when you click OK on the Event Entry form if you entered Container in the Event Category field for a real-time event or if you entered XAPI in the Event Type field.	Link single events to a container event.

A.6.3 Entering a Single or Container Event

Access the Event Entry form.

Figure A-2 Event Entry form

Description of "Figure A-2 Event Entry form"

Event Name

The name of the event (for example, JDERTSOOUT). Single events can be part of other events.

Event Description

The description of an event.

Event Type

A value that represents the name of the event type (for example, the value RTE denotes Real Time Event; the value ZFILE denotes Batch Upload Event).

If you are adding XAPI events, the system automatically completes the Event Category field with Container and after you click OK, the Event Definition Detail form appears. Complete the Data Structure and Data Description fields, and then click OK.

Event Category

The category of the event, for example, single event or event container.

Product Code

A user defined code (98/SY) that identifies a system. Values include:

01: Address Book

03B: Accounts Receivable

04: Accounts Payable

09:: General Accounting

11: Multicurrency

Reliable Delivery

An option that specifies whether the system retransmits and stores failed events. If you clear this option, the system does not retransmit or store failed events. When you select this option, the additional processing might negatively impact system performance. Values are:

1 or Y: Retransmit and store failed events.

0 or N: Do not retransmit or store failed events.

If you are using the Reliable Event Delivery feature, you must set the Reliable Delivery field to reliable (1 or Y) and the Timeout Threshold field must be set.

Timeout Threshold

The Timeout Threshold field is in seconds and applies only to the reliable events for which an initial delivery attempt fails. This field determines the maximum amount of time that has to pass from the event creation to the time when the event will be discarded if not delivered successfully. Events with a threshold of zero never expire.

Data Structure

The name of the data structure that passes event information.

This field disappears if Container is the value of the Event Category field; however, when you click OK, the Event Definition Detail form automatically appears for you to enter data structure information.

A.6.3.1 Event Definition Detail

Access the Event Definition Detail form.

Figure A-3 Event Definition Detail form

Description of "Figure A-3 Event Definition Detail form"

Event Data

An option that enables you to define single, individual (composite) events for a container event.

Data Structure Data

An option that enables you to define aggregate events for the container event. For XAPI events you must select the Data Structure Data option.

A.6.4 Changing the Status of an Event Record

Access the Event Definition Workbench form.

To change the status of an event:

1. Complete these fields:

   • Event Name

   • Description

   • Event Type

   • Product Code

2. Click the All Statuses option, and then click Find to display existing events.

3. In the detail area, select the event for which you want to change the status.

4. From the Row menu, select Change Status.

5. To view the status change, click Find.

   Note:

   The status of the event is the same for all environments. If the event is active, that event is active for all environments. If the event is non-active, that event is non-active for all environments.

A.7 Adding Logical Subscriber Records

This section provides an overview of the logical subscriber and discusses how to add a logical subscriber record.

A.7.1 Understanding Logical Subscribers

Use the Interoperability Event Subscription program (P90702) to add a logical subscriber. You can also view and modify existing logical subscribers. The Interoperability Event Subscription table contains subscriber information, such as the machine name and port number, and is read by EVN. If subscriber information is missing for the XAPI event, the system generates the event but cannot deliver it.

A.7.2 Forms Used to Add a Logical Subscriber

Form Name	FormID	Navigation	Usage
Subscriber Workbench	W90702A	Enter P90702 in the Fast Path.	Locate and review existing subscription information.
Work With Logical Subscriber	W90702D	On Subscriber Workbench, select Logical Subscriber from the Form menu.	Review existing logical subscribers.
Logical Subscriber Entry	W90702B	On Work With Logical Subscriber, click Add.	Add a logical subscriber.

A.7.3 Adding a Logical Subscriber

Access the Logical Subscriber Entry form.

Figure A-4 Logical Subscriber Entry form

Description of "Figure A-4 Logical Subscriber Entry form"

Logical Subscriber Name

A value that uniquely identifies a subscriber.

Do not use spaces in the logical subscriber name.

Event Transport Driver

The name of the transport driver that delivers events to the subscriber (for example, JDENET).

Host Name

The name of the server that processes events for the subscriber.

Port Number

A number that identifies the port where the subscriber service is running.

Subscriber Group

A user-defined name that specifies how to deliver events for the subscriber. For example, if you are using a WSG adapter, enter the name of the adapter.

A.8 Entering Subscription Information

This section provides an overview about subscription information and discusses how to:

• Add subscription records.

• Change the status of a subscription record.

A.8.1 Understanding Subscription Records

You use the Interoperability Event Subscription program (P90702) to add new subscription information for XAPI events and to review and change existing subscription information. You can also add a subscription by copying and then modifying an existing subscription, and you can delete subscriptions. You can access and view your real-time and XAPI event definitions by selecting Event Definition from the Form menu. You can also access and view Z events when you click the Z File Events button on the Subscriber Workbench form or by selecting the Z File Events option on the Form menu.

Note:

When you add to or modify the F90702 table, you must restart the server for the changes to become effective.

A.8.2 Forms Used to Enter Subscription Information

Form Name	FormID	Navigation	Usage
Subscriber Workbench	W90702A	Enter P90702 in the Fast Path.	Locate and review existing subscription information.
Subscriber Entry	W90702F	On Subscriber Workbench, click Add.	Add a subscription.

A.8.3 Entering a Subscription Record

Access the Subscriber Entry form.

Figure A-5 Subscriber Entry form

Description of "Figure A-5 Subscriber Entry form"

Event Subscriber

The user ID for a subscriber.

Event Environment

A value that identifies the environment that the event is executed in.

Purpose

A user defined name or remark.

Logical Subscriber Name

A value that uniquely identifies a subscriber.

Event Type

A value that represents the name of the event type (for example, the value RTE denotes Real Time Event and the value ZFILE denotes Batch Upload Event).

Event Name

The name of the event (for example, JDERTSOOUT). Single events are part of other events.

Event Filter Name

The system automatically enters Filter0.

A.8.4 Changing the Status of a Subscription

Access the Subscriber Workbench form.

To change the status of a subscription:

1. Complete these fields:

   • Subscriber Name

   • Purpose

2. Select the All Statuses option, and then click Find to display existing subscriptions.

3. In the detail area, select the event for which you want to change the status.

4. From the Row menu, select Change Status.

5. To view the status change, click Find.