EnterpriseOne 8.12 / XML / Tools Release 8.96

[nailzscott]

We are running EnterpriseOne 8.12 on SQL Server, with the 8.96 tools release and having timing issue while using 3rd party data collection software - which uses a lot of XML processes. Trying to work with Oracle who state that large scale improvements to XML process with next tools release - 8.97. We setup debug in DV environment for simple work order test, one lot completion with quality testing tied to item. This generated 13mb of over 120 log files, which are next to impossible to review. Looking for anybody with similar experience and some guidance. Cannot practically go to 8.97 tools yet due to aggressive plant go-live schedule and no test time. Hope someone can help.
Thanks. Scott

 

[cmanderson]

Do you mind naming the third party data collection software, and also the configuration of the Enterprise Server(s) used for the interface, including a partially obfuscated JDE.INI from the Enterprise Server?

I've had some experience with a large DSI conversion from local processing on 17 fat clients to a single Enterprise Server with ample resources. There were between 50 and 60 plant locations live on the system, and as I recall between 100 to 300 users online depending on the time of day.

 

[JEMILLER]

If you are referring to DSI I can speak from experience going from 8.96 to 8.97 on 8.12 with a high-volume site. If you are speaking of another vendor such as RF-SMART or CDI some of my comments should apply. I haven't worked with those products but I am aware that they use the XML interface.

Improvements have definitely been made to the XML processing in 8.97 but that is only a piece of the performance improvements that have been made to DSI recently. DSI have worked closely with Oracle to improve their function caller and to develop more accurate sizing models (for JDE.INI and DSI configuration settings) for the multi-threaded kernels in 8.96 and above. Oracle has in turn improved the XML functionality with information from DSI sites (a number of POC fixes originate from one of the sites I work with). Fairly recently DSI released an "advanced function caller" that uses persistent XML sessions. Prior to that they established a new session with JDE for each XML call they made. Session establishment takes 1 to 3 seconds depending on your hardware. I don't know if they have made an 8.96 version of their new function caller. It might be worth a try.

I have found other problems with DSI performance that are not related to the XML link itself. DSI uses wrapper NER business functions that emulate what the interactive applications would call for the same business process. Depending on your setup and any customizations the DSI wrapper functions may not behave perfectly. Specifically I have found issues with cache memory not being freed and growing memory allocation of the call object kernels. There are a number of DSI-specific ESU's to address some of these problems.

Besides getting fix-current with ESU's and Tools release my approach to troubleshooting XML call object performance is to take a large volume of call object log files like the 120 you mentioned and run them through the JDE Performance Workbench tool and compare statistics for each run. I look for functions or particular runs that stick out as consuming more time than other calls. I then drill into that particular log to investigate. A specific query or specific type of transaction might stand out as the poor performer. I have developed some scripts to help automate submitting a mass of logs to the PW.

Another tool at your disposal is the DSI-side API call timings. These are stored in a DSI table and can be queried to look for spikes in transaction time.

There are a variety of things that can affect XML transaction performance. Figuring out the problem requires correlating information from a number of sources.

With a tight schedule I understand that is may be difficult for you to get fix-current. At the least if you are using DSI and have not had them run your configuration through their kernel configuration sizing tool I highly recommend that you get in touch with them.

 

[nailzscott]

Charles, thanks for the response. Do to client confidentiality, I cannot provide the 3rd party resource name, but I can tell you it is not DSI. On the JDE.ini - this is a hosted solution where IBM manages the box. If there is a particular portion of the ini file that would be of interest, I can ask our cnc resource at the host if I can get that piece. Our platform is Windows 2003 SP2, with MSSQL server DB.

On your DSI solution that you reference- that solution uses XML, correct? Was that an 8.12 install? If so, what Tools release. I'm trying to convince project mgt that we should move to 8.97 tools, but I'm looking for others who may have had similar circumstances and who might have seen improvement on the new tools. I have worked with this data collection group on several installs in the past and we have never seen anything like these delays on transactions. On prior installs, transactions were in milli-seconds; but our hosted solution CNC folks, and the data collection folks, and me are stumped on this one. By the way, there are probably no more than 40 sequential users on
Thanks for any help you can provide.

 

[nailzscott]

JEMILLER. My project is not a DSI project, but my understanding is that the 3rd party data collection processes typically use XML. With your DSI high volume site, did you have any large scale performance/timing improvements when going to 8.97 from 8.96? Thanks for the info on the JDE performance workbench. Very odd the Oracle did not mention that to me when I entered an SR for their help in reviewing logs.
Thanks
Scott

 

[JEMILLER]

Scott,

If your 3rd party uses XML interoperability then yes, 8.97 should help performance. Whether it fixes your problem depends on whether or not the problem sits in the XML mechanism. There are so many other things that can cause timeouts/slowdowns when you link to E1 via XML. 8.97 was a piece of the solution for my high-volume client but it was not the only piece.

As for why Oracle didn't mention performance workbench that isn't that unusual. Many of the support people know of PW but may not have the experience to run it or interpret the results. You have to move higher up the chain before someone is going to ask for your debug logs and consider using PW to analyze them. The first plan of attack is always to get you fix-current which makes a certain amount of sense.

Can you apply 8.97 to a non-production environment using a multi-foundation setup? That will tell you relatively quickly if 8.97 is going to solve your problem.

 

[nailzscott]

JEMILLER, I appreciate the update.
I have gone through the PW with the Call Object logs that we generated during our tests. If I am interpreting them correctly, there do not seem to be any delays at that point. It seems to me that a better JDE tool would be one that takes all of the debug logs generated and allow for sequencing by time stamp, so you could see the string of events in time. Anyway, we are still drudging through the logs but not getting anywhere fast.
I have suggested to the client that we install 8.97 asap, but they are not willing to do it now due to schedules. I talked to our hosted CNC group about the install of 8.97 to non production, but they said that due to the differences, if we had 8.97 in non prod and 8.96 in Prod, we would not be able to do normal package promotions.
Thanks for the input though.
Scott