My blog has moved!

Visit http://blog.adamroderick.com/ and update your bookmarks.

Tuesday, April 29, 2008

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.

Labels:

Thursday, April 17, 2008

Enterprise Line of Business Adapter Tracing

I am working with the BizTalk JDE adapter, and this is a very handy feature. A couple of times already I was just stuck, but examining the trace logs gave me the additional information I needed to troubleshoot my error. I do not have a lot of experience with tracing, so it took me a bit to catch on to exactly how it works.

The documentation is here. Here are my exact steps:
  1. Download and install the Windows Server 2003 Platform SDK (google it to find the version you need--I was developing on Windows Server 2003). All you really need is one file--tracelog.exe
  2. Copy tracelog.exe to your adapter installation directory. Mine was C:\Program Files\Microsoft BizTalk Adapters for Enterprise Applications\J.D. Edwards EnterpriseOne(r)\Bin
  3. Open a command prompt and go to that same directory. Run the command BTAJDEEnterpriseOneTrace.cmd -transmitter -start. This uses tracelog.exe to start a trace.
  4. Run whatever BizTalk-to-JDE process is giving you problems.
  5. From the command prompt again, run the command BTAJDEEnterpriseOneTrace.cmd -transmitter -stop to stop the trace.
  6. Run the command tracerpt C:\rtlog.etl -o C:\log.csv, where C:\log.csv is where you want your report to go.
  7. This is now a CSV file containing much more information than what the adapter sends to the event log. I opened Excel and imported the data to make it more readable.

Labels: ,

Tuesday, April 15, 2008

Exception occurred when persisting state to the database

I have seen this error occur for more than one reason, but today was a new one for me. In the Application Event Log, an error for a suspended orchestration states:


Inner exception: Exception occurred when persisting state to the database.


Further down, it gives a little more detail, but it is still unclear what caused the error:


A batch item failed persistence Item-ID b3a8257e-c840-4f91-88da-a41b00c7333b OperationType MAIO_CommitBatch Status -1061151960 ErrorInfo An error occurred when accessing the part data or one of its fragments. The part data or fragment may not exist in the database.


Turns out it was related to a map. The root cause of this error was that the map was generating output that was invalid according to the output schema. Sure enough, I tested the map with the message from the suspended orchestration, and the output was invalid. Once I changed the map and it passed testing, the error did not occur.

Labels:

BizTalk and Virtual PC

Always use SysPrep or some other cloning tool to make copies of virtual hard drives. I am working on a project to interact with Commerce Server 2007. I am developing on a virtual machine that is a copy of the virtual machine that is running Commerce Server. I just could not get the Orders Receive Adapter to work. It kept giving the following error, which is MSDTC related:


Failed submitting message to BizTalk. Message: The transaction has already been implicitly or explicitly committed or aborted (Exception from HRESULT: 0x8004D00E).


After working on the MSDTC settings on both virtual machines, the real error finally showed up in the event log:


The local MS DTC detected that the MS DTC on COOKIMAGE has the same unique identity as the local MS DTC. This means that the two MS DTC will not be able to communicate with each other. This problem typically occurs if one of the systems were cloned using unsupported cloning tools. MS DTC requires that the systems be cloned using supported cloning tools such as SYSPREP. Running 'msdtc -uninstall' and then 'msdtc -install' from the command prompt will fix the problem. Note: Running 'msdtc -uninstall' will result in the system losing all MS DTC configuration information.


On my local development machine (the one running BizTalk, not the one running Commerce Server), I uninstalled MSDTC, had to reboot before reinstalling, reinstalled MSDTC, and reconfigured MSDTC. The Orders Receive Adapter is now functioning correctly.

Labels: , ,