BizTalk JDE Adapters and the JDEUTIME data type

The BizTalk Enterprise Line of Business J.D. Edwards Adapter does not support the JDEUTIME data type. JDEUTIME is a timestamp in Coordinated Universal Time (UTC).

The error appearing in the event log did not tell me much:

E-JDE0045: ExecuteMethod failed to execute module N0100042 business function MBFCustomerMaster. JDEdwards error message: java.lang.ArrayIndexOutOfBoundsException: 234 >= 234

What this was actually telling me was that I was sending in 234 parameters when calling the business function, but JDE was expecting more parameters. The parameters become an array, and when JDE tried to access the value at index 234, it was beyond the bounds of the array, and threw an exception. Not very apparent from the error text, but it makes sense now that I understand it.

What really helped was when I ran a trace on the adapter while calling the business function, and the trace captured an additional error message. The exact text was

I-JDE0035: Type UTIME is not recognized for the argument DateEntered in the method MBFCustomerMaster - this method will not be available for browsing or calling

Working with the customer, I learned that my schema that I generated using Add Adapter Metadata was missing the JDEUTIME field and all following fields. I attempted to manually add the fields to the schema using xsd:string as the type of the JDEUTIME field, but the call continued failing with the I-JDE0035 error.

I have been working with Microsoft support, who have a request to the BizTalk development team to consider adding support for the JDEUTIME parameter. We have decided to have the client write a wrapper business function that does not include a JDEUTIME parameter, since that parameter is not critical to our process. The wrapper function will pass the values to the business function we need to call, and then return the response back to BizTalk.

Below is an excerpt from the JDE documentation about why UTC time is important:

In order to provide some clarity, lets look at a real example. For this example lets have the enterprise server in Denver (GMT -7) and a user located in Sydney, Australia (GMT +10). There is a 17-hour difference between these two locations. This 17-hour difference means that Denver and Sydney share the same date for only a 6-hour period of time. If the user in Sydney enters a new Sales Order in P4210 on October 13, 2003 at 11:00AM, this corresponds to October 12, 2003 at 6:00PM in Denver. If the Denver office then runs a Sales Order Update at 10:00PM on October 12, to update all the sales order for that day, it will miss the Sydney order as its date stamp (October 13) is in the future. This means that this sales order would not be updated until the next day in Denver. If you reverse the enterprise server and the user, then we have the possibility of this sales order never getting updated at all by the Sales Order Update process.

Lets look at one more Sales Order Entry example where time would be important with respect to a date. In this example a user is taking a sales order in Denver for a Customer in Australia. As part of this process we need to calculate when the package will arrive at the customer site. The order is placed on 10/13/03 at 5:00 PM in Denver, which for the Australian customer is 10/14/03 at 10:00 AM. Lets assume that we know this package will be picked up, by the delivery service in Denver, on the morning of 10/14/03 at 9:00 AM, and that delivery will take three working days. If we are cognizant of time zone information, we will correctly calculate the delivery date as 10/18/03. Without time zone information, the customer would be expecting the package on 10/17/03.