This appendix contains the following topics:
Section E.1, "Understanding the Events Self-Diagnostic Utility Tool"
Section E.3, "Events Self-Diagnostic Utility Tool Components"
The Events Self-Diagnostic Utility Tool supports Z events and real-time events. Normally, your system administrator runs the Self-Diagnostic Utility Tool to verify that your events infrastructure features are functional. The Self-Diagnostic Utility Tool can be used on these platforms:
Windows 2000 and NT
IBM i
HP
Sun
AIX
The Events Self-Diagnostic Utility Tool analyzes the infrastructure of an event and reports configuration, kernel, and network problems that are detected as the event is processed through your system. You can use the tool to perform a comprehensive analysis, or you can configure the tool to perform an analysis that is specific for your needs. The Events Self-Diagnostic Tool uses the XML comparator to compare XML documents to detect the presence of any data corruption in event information. The tool also suggests actions that you can take to resolve problems. You can run this tool on either a server or a client or both.
After an event is generated at the call object API on the server or the application API on the client, problems that cause the event to fail can occur. This list identifies problems that might occur:
The jde.ini file has a configuration error.
The ZEVG library is unavailable or the IEO or EVN kernel process is down.
Subscribers and supported events have not loaded successfully.
One or more of the kernels involved in the event delivery is corrupting the event information.
The network link between any or all of the components involved in this infrastructure is permanently down.
When the Events Self-Diagnostic Tool detects a problem, the tool sends messages to you explaining the problem and suggesting resolutions and also logs the error in the appropriate log files. The message that is sent to you indicates which log files you should review. This list provides some examples of how the Events Self-Diagnostic Tool detects problems:
Performs an in-depth interoperability-oriented analysis of the jde.ini file.
Reads the F90701 table to determine whether the event is defined.
Reads the F90702 to determine whether the persistent subscription/unsubscription request, which is sent to the EVN kernel by the tool, is successful.
Reads the Object Configuration Manager to find the location of the IEO kernel.
In this process, the tool ensures there is only one active entry for the RTE object.
Checks inter-connectivity within events infrastructure by sending self-diagnostic connectivity message calls.
Generates self-diagnostic events to test different services that are offered by the infrastructure and to verify event information against possible data corruption.
Note:
This list is general and not all-inclusive.The Events Self-Diagnostic Utility Tool consists of three components:
Event generator
Event receiver
XML comparator
The Events Self-Diagnostic Utility Tool starts with an event generator process. During startup, the event generator performs basic background analysis of the events infrastructure, which include:
Verification of interoperability specific sections of the jde.ini file.
Verification of real-time events definition.
Inter-component connectivity check within the events infrastructure.
If startup is successful, the event generator tests different features offered by the events infrastructure. These features include generating and testing different types of events, listing the valid events, checking the event template, and testing subscription information. You can run one or more of these tests by using one of these methods:
Running the test against an existing configuration file that you previously set up.
Running the test against a new configuration file, which you will set up.
Selecting options and executing the test from the command line menu of the tool.
After successful generation of a self-diagnostic event, the event is passed through the event infrastructure system. To test the accuracy of the event information that is being conveyed through the system, the event generator attaches an additional packet, in the form of XML stream, to the event. The diagnostic XML packet contains information about the event. At each stage of communication, each kernel (or component) verifies the event information by comparing standard message packets with the self-diagnostic XML packet. The kernel (or component) logs the result of this comparison at each point of comparison in respective log files. The accuracy of the information in template requests is tested the same way.
The event receiver acts as a NULL transport driver that subscribes itself for self-diagnostic events during EVN kernel startup. The event receiver compares and verifies the XML documents contained in the received self-diagnostic events. The event receiver logs the result of this comparison in the EVN kernel log file.
The event generator uses the XML comparator tool to test the accuracy of event information or of an event template request that is being passed through the system. The XML comparator compares any two given XML documents for equivalency, similarity, or both. To perform the comparison, the XML comparator requires three XML documents. Two of the documents are the actual XML documents to be compared. The third document is an exclusion XML document that contains nodes that are to be ignored during the comparison of the two given XML documents.
When you select the Customize Tool option from the Interface menu, the tool prompts you to provide a new file name or to use an existing configuration file (one that you previously created using this tool). The tests (actions) and options for each test are the same tests that are discussed previously.
To use an existing configuration file (an XML file that you previously created), type the filename at the prompt and press Enter or Return. This action starts the diagnosis against your previously built configuration file.
To create a new configuration file, type a filename using XML as the extension, and then press Enter or Return. The tool offers the same tests that are on the Command Line Execution menu. You can select one or more tests by using a comma to separate the test numbers.
This section provides overviews of each of the self-diagnostic tests that you can run when you execute the Events Self-Diagnostic Tool
To use the Event Self-Diagnostic Tool, you must have a valid JD Edwards EnterpriseOne user ID, password, environment, and role. If you are using the tool from a JD Edwards EnterpriseOne server and you do not supply this information as parameters, the user name, password, environment, and role information is read from the security section of the server jde.ini file. If you are using a client, you must enter a valid JD Edwards EnterpriseOne user name, password, environment, and role. If you do not enter this information, the tool stops. If you are generating events from a client, you must also have a valid OCM mapping for RTE or Z events to a valid server. Before you run the Events Self-Diagnostic Tool:
Ensure PORTTEST runs successfully on your system.
Ensure that one instance of the IEO and EVN kernel is running.
Ensure self-diagnostic events are defined in the F90701) table.
To start the Events Self-Diagnostic Tool on the JD Edwards EnterpriseOne Server, double-click the executable file at this location: $system\bin32\sdtool.exe
Or you can pass parameters, for example: $system\bin32\sdtool.exe username password environment role
To start the tool from the client side, you must include these parameters: $system\bin32\sdtool.exe username password environment role
Note:
$system refers to the path where the application is installed on your system.The Events Self-Diagnostic Tool accesses the Security section of the jde.ini file for a valid user name, password, environment, and role. Upon startup, the tool analyzes the jde.ini file, verifies that events are defined, and checks the inter-component connectivity within the events infrastructure. As the tool analyzes each of these areas, it provides you with feedback about what is being analyzed and whether the analysis was successful.
If the tool detects a problem in any one of the startup areas, the tool terminates the diagnosis and sends you a message that explains the problem encountered and suggesting actions for resolving the problem.
After successful startup, you have a choice of creating and using a customized configuration file or using the command line of the tool to run the diagnosis. The Customized Tool option enables you to build and save a diagnostic test to a file so that you can run that test as often as needed without having to reenter information into the tool. When you use the Command Line Execution option, you must enter the test information when the tool prompts you. When you run tests from the command line, the Interface menu always follows the results statements so that you can run another test or exit the tool.
Whether you select Option 1, Customize(d) Tool, or Option 2, Command Line Execution, the tests that the tool performs are the same.
You can select one or more tests by typing the number that is associated with the test at the prompt and then pressing Enter or Return. For multiple tests, separate the number of the test with a comma (,). Some of the tests provide further options. At the prompt, you enter one or more options, using a comma to separate multiple options. The tool performs the test and provides feedback to you indicating success or failure. If the test failed, the tool provides feedback that tells you that the test failed and identifies the logs you should review for more information.
When you select Action 1, Generate/Test Real Time Event(s), the tool displays the real-time event types from which you select one or more real-time event types to test.
The tool generates the real-time event you requested and attaches a self-diagnostic XML document to the event. The event contents are verified for any data corruption against the attached XML document at each kernel in the events infrastructure and event receiver transport driver. You receive a message indicating whether the event was successfully generated. You also receive this feedback message: Please see log files corresponding to IEO and EVN for any present event data corruption. This message tells you to look at the log files to determine whether an XML document mismatch occurred. The tool also provides a final message that indicates that the tool has completed the analysis for that action, and then it returns you to the tool interface menu.
When you select Action 2, Generate/Test Z Event, the tool displays another set of options. You can test a simulated Z event and you can test a Z event that uses the actual interface tables (Z tables). If you test a simulated Z event, the tool generates a simulated Z event and attaches a self-diagnostic XML document to the event. The event contents are verified for any data corruption against the attached XML document at the EVN kernel and event receiver transport driver. You receive a message indicating whether the event was successfully generated. You also receive this feedback message: Please see log files corresponding to EVN for any present data corruption. This message tells you to look at the EVN log file to determine whether an XML document mismatch occurred. The tool also provides a final message that indicates that the self-diagnostic tool has completed the analysis for the action, and then it returns you to the tool interface menu.
If you generate an actual Z event, you must have a valid UBE and you must set up the appropriate interface tables. The tool asks you for your user name, batch number, transaction number, line number, transaction type, document type, and sequence number. The tool uses the live interface tables (Z tables) for this test. When you request an actual Z event, the tool generates the Z event but does not include a self-diagnostic XML document. The EVN kernel returns a message that indicates whether the event was successful. Because no self-diagnostic XML document exists, the tool cannot diagnose data corruption.
When you select Action 3 (Test all types of events) from the Execution menu, the tool tests all of the real-time events (single, aggregate, and composite) and both Z events (simulated and actual). Action 3 is the same as Action 1 (all three options) and Action 2 (both options) combined. For the real-time events and the simulated Z event, the tool generates the event and attaches a self-diagnostic XML document to the event so that any data corruption can be detected. If you select this action, you must have a valid UBE and you must set up appropriate interface tables. If you run this test but do not have actual Z event data, you can abort that portion of the test by entering Exit when the tool asks for the Z event information.
The tool sends the event information to the IEO and EVN kernels, and the kernels return messages indicating whether each event was successful.
When you select Action 4, Get Event List (List of events supported) from the Execution menu, the tool immediately runs the test.
The tool sends a getEventList request to the EVN kernel. The EVN kernel responds with the list of event names that you have defined. To validate that the list is complete, the tool checks the list for the presence of self-diagnostic event names. The tool provides a list of the events to you along with a message indicating whether the test was successful.
When you select Action 5, Get Event Template, the tool displays the real-time event types that have a template associated with them.
The tool generates the template request and attaches a self-diagnostic XML document to the request. The template request is verified for any data corruption against the attached XML document at each kernel in the events infrastructure and event generator. The tool provides feedback that the template request was successful and that the template data was validated against the XML packet. If the test fails, the tool provides a message that indicates the reason for the failure.
When you select Action 6, Subscription Services, the tool displays a set of options for the type of subscription service to be tested.
When you select the Persistent Subscribe option, the tool sends a persistent subscription request for a registered self-diagnostic event to the EVN kernel. The tool verifies the list of subscribers that are maintained in a file or from the database table (depending on how your system is configured), and then sends you a message indicating whether the test was successful.
When you chose the Persistent Unsubscribe option, the tool sends a persistent unsubscription request for a registered self-diagnostic event to the EVN kernel. The tool verifies that the subscription is no longer in the file or database table (depending on how your system is configured), and then sends you a message indicating whether the test was successful.
When you select the Non-Persistent Subscribe option, the tool sends a non-persistent subscription request for a registered self-diagnostic event to the EVN kernel. The tool verifies the list of subscribers that is kept by the EVN kernel, and then sends you a message indicating whether the test was successful.
When you select the Non-Persistent Unsubscribe option, the tool sends a non-persistent unsubscription request for a registered self-diagnostic event to the EVN kernel. The tool verifies the subscription is no longer in EVN, and then sends you a message indicating whether the test was successful.