This chapter contains the following topics:
XML Dispatch is XML-based interoperability that runs as a JD Edwards EnterpriseOne kernel process. The XML Dispatch kernel is the central entry point for all XML documents. For incoming XML documents, XML Dispatch identifies the kind of document that comes into JD Edwards EnterpriseOne and sends the document to the appropriate kernel for processing. If XML Dispatch does not recognize the document, XML Dispatch sends the document to XTS to recognize and transform it into native JD Edwards EnterpriseOne format. After XTS transforms the document, the document is sent back to XML Dispatch to be sent to the appropriate kernel for processing. For outgoing documents, XML Dispatch remembers whether the request document was transformed into JD Edwards EnterpriseOne native format. If the incoming request was transformed, then the outgoing response document is sent to XTS for transformation from native JD Edwards EnterpriseOne format back into the format of the original request. After XTS transforms the document, the document is sent to XML Dispatch to distribute to the originator.
The XML Dispatch kernel is able to route and load balance the XML documents. For example, if you have many XML CallObject message types coming in at once, XML Dispatch tries to instantiate a new CallObject kernel. You set up the number of instances that a kernel can have in the jde.ini file. For example, if you set the number of instances for the CallObject kernel to five, if more than one CallObject document comes into JD Edwards EnterpriseOne, XML Dispatch sees that a particular kernel is busy and instantiates another one (up to five instances). XML Dispatch is able to recognize new kernel definitions (such as XAPI) if the kernel is defined in the jde.ini file. You are not required to change JDENET code when new kernels are added.
XML Dispatch is available on all platforms that are supported by JD Edwards EnterpriseOne.
XML Dispatch receives standard JDENET messages (in the form of XML documents) from a transport driver or other jdenet_n. The communication between a transport and XML Dispatch is local inter-process communication (IPC) using JDENET APIs. The communication between XML Dispatch and XTS and between XML Dispatch and XML kernels can be either IPC or remote network using JDENET APIs.
XML Dispatch uses recognizers to determine how to handle incoming and outgoing XML documents. If XML Dispatch recognizes an incoming XML document as being in JD Edwards EnterpriseOne native XML format, the XML document is parsed and sent to the appropriate kernel. For outgoing documents, the recognizer determines whether an XML document can be left as JD Edwards EnterpriseOne native XML format or whether it must be transformed.
You can add more than one recognizer to XML Dispatch to recognize different XML grammar. XML Dispatch recognizes the these types:
The XML Dispatch recognizer raises DocIsRecognized exception on document identification to stop further parsing.
You can write a recognizer that is able to recognize other types of XML documents. The specification for the type is configured in the jde.ini file.
As part of XML Dispatch, you can write a transport. Transports communicate with external systems using mechanisms such as MQ WebSphere, MSMQ, HTTP, TCP/IP, and so on. Transport processes must run on the same machine as XML Dispatch. To develop a custom transport to communicate with JD Edwards EnterpriseOne, use these APIs:
The transport APIs assume a polling model, which means calls to put or receive messages are given without a time-out.
These settings are for a Microsoft Windows platform:
krnlName=XML DISPATCH KERNEL dispatchDLLName=xmldispatch.dll dispatchDLLFunction=_XMLDispatch@28 maxNumberOfProcesses=1 numberOfAutoStartProcesses=1
This table provides the different .dll extensions for other platforms.
|SUN or RS6000||libxmldispatch.so||?XMLDispatch?|
XML Dispatch uses the settings in the [XMLLookupInfo] section of the jde.ini file to route XML documents to the corresponding XML kernels. The system uses three keywords (XMLRequestN, XMLKernelMessageRangeN, and XMLKernelHostN) to map a pair that consists of an XML request and an XML kernel. A description of the settings in the [XMLLookupInfo] section are explained in this table:
|XMLRequestTypeN=||Identifies the type of message to be processed.|
|XMLKernelMessageRangeN=||A hard-coded number that identifies the kernel message range.|
|XMLKernelHostNameN=||The name of the host.|
|XMLKernelPortN=||Value is 0 or 1. To indicate a local host, enter 0. To indicate a remote host, enter 1.|
|XMLKernelRplyN=||Value is 0 or 1, with 1 as the default value. A value of 0 indicates no reply is required. A value of 1 indicates a reply should be returned to the originator.
Note: XMLKernelRplyN setting is not required for list, callmethod, and trans. The reply setting is an implied 1.
XMLService does not send a response, and the setting for XMLKernelReplyN should be zero (0).
Where N starts with 1, and multiple groups of these keys can be in this section.
The [XMLLookupInfo] section should have six groupings, as illustrated in this example:
[XMLLookupInfo] XMLRequestType1=list XMLKernelMessageRange=5257 XMLKernelHostName1=local XMLKernelPort1=0
XMLRequestType2=callmethod XMLKernelMessageRange2=920 XMLKernelHostName2=local XMLKernelPort2=0
XMLRequestType3=trans XMLKernelMessageRange3=5001 XMLKernelHostName3=local XMLKernelPort3=0
XMLRequestType4=JDEMSGWFINTEROP XMLKernelMessageRange4=4003 XMLKernelHostName4=local XMLKernelPort4=0 XMLKernelReply4=0
XMLRequestType5=xapicallmethod XMLKernelMessageRange5=14251 XMLKernelHostName5=local XMLKernelPort5=0 XMLKernelReply5=0
XMLRequestType6=realTimeEvent XMLKernelMessageRange6=14251 XMLKernelHostName6=local XMLKernelPort6=0 XMLKernelReply6=0
XMLRequestType7=ube XMLKernelMessageRange7=380 XMLKernelHostName7=local XMLKernelPort7=0 XMLKernelReply7=1
The XML Dispatch kernel uses these two additional settings:
[XML DISPATCH] PollIntervalMillis=3000
The PollIntervalMillis setting is the number of milliseconds that the XML Dispatch kernel sleeps during inactivity when it is waiting on responses from other XML kernels such as XML CallObject. The lower this value, the more CPU cycles the XML Dispatch kernel uses when waiting for responses.
The ResponseTimeout setting is the number of seconds that the XML Dispatch kernel waits for a response from other XML kernels, such as CallObject) before giving up on the response.
|XML Dispatch Error||How XML Dispatch Handles the Error|
|An error occurs while XML dispatch, XTS, and the XL kernel processes are exchanging data. For example, communication is broken.||XML Dispatch generates an error report, which is an XML document that describes the error.|
|An error occurs while the parser or XTS is processing an XML document. For example, a syntax error, an invalid request, and so on.||XML Dispatch generates an error report that is based on the error message that is generated by either the parser or XTS.|
|An error occurs while an XML kernel is processing an XML document. For example, the user name is invalid, the transaction is rolled back, and so on.||XML Dispatch uses XTS to transform the XML kernel generated error report when necessary.|
XML Dispatch sends generated error reports to the corresponding transport process.
You can use the XML interoperability solution (XML Callobject and XML List) to submit a UBE that requests inbound XML. The COM connector, Dynamic Java connector, and Java connector support inbound synchronous XML requests. You can use the run RUNUBEMXL command; however, this command works only on the JD Edwards EnterpriseOne Enterprise server.
Before you request an inbound XML, do the following:
Configure the JD Edwards EnterpriseOne server jde.ini file, [XMLLookupInfo] section for XML Request type 7, as illustrated here:
[XMLLookupInfo] XMLRequestType7=ube XMLKernelMessageRange7=380 XMLKernelHostName7=local XMLKernelPort7=0 XMLKernelReply7=1
Create a processing option that contains data selection and data sequencing that you want and submit from batch version to make sure that you obtain the desired result.
For example, R0010P creates a new version, ABCD (where company=00001.)