E9200 Integration Options

One unique sales order, with varying degrees of complexity, multiple lines, adv pricing, costing etc...about 2.5 hours to load. We are testing on Oracle Public Cloud. We are testing on AWS as I type. I expect AWS to far outperform OPC, which tends to run in the vicinity of 90-99% percent oCPU utilization. (So Oracle needs to get that fixed. Something I am sure we can all agree on.) Never the less, the performance from AIS was indeed shocking. Speaks volumes to the optimization engine that gets better with each release.
 
Never the less, the performance from AIS was indeed shocking

I respectfully disagree. Try loading the data through SQL to the Z tables and run it through. I bet you it will finish within 10 minutes! And if you have the resources, try loading one 10,000 line journal entry through AIS. Our product can do this less than 90 seconds! Here is the YouTube link, see for yourself: https://www.youtube.com/watch?v=BK2xhpxMnJo


I think most people diminish AIS by calling it a screen scraper.

It is really the concept of it, that's why I presented the gmail analogy in a previous response to this thread. There are additional, non-technical reasons as well .. if we meet in person, I will be happy to share those.
 
Harry - this is devolving the thread. If you have a specific performance benchmark that can demonstrate AIS vs BSSV vs Z Tables/EDI - then I'm sure that would be of interest to the entire community. However, JDE Customers KNOW there are a ton of other integration solutions out there including Aellius, Magic and everyone else. Just like theres a ton of integration types to other ERP manufacturers' products. But JDE has always provided core, built in, integration technologies - and AIS is one of those types.

AIS works a LOT faster than you're portraying. Try sending thousands of sales orders into AIS in parallel. It works exceptionally well.
 
We've tested concurrently with Z tables. We are no where near 10 minutes on a Z file upload. I am interested in testing journal entries. We'll add that to our list of use cases. While the genesis of AIS could be construed as a screen scraper, the functionality in my previous post, vis a vis app stack capabilities, query, etc...really moves the process beyond basic screen scraper technology. I'm always happy to meet and discuss in person.
 
Jon - I will get a benchmark on Journal Entry through AIS vs our product and post it here.
 
Fair enough and I'm sure we all appreciate that. I do not read "screen scraper" as "simple" or "small", I think we are really referring to the intrinsic overheads of this implementation here, in fact we even emphasize the complexity of it. And of course, while exposing this functionality in a much more controlled fashion than any other approach has clear good sides, the more fiddly low-level approaches do offer extra flexibility and speed. Which squarely brings us back to the original interface requirements: whether it's something big or something small would dictate what approaches are available to you in the end. And selecting a wrong approach would make your path so much longer and more painful...

In my opinion, far too often, the approach selection boils down to available skillsets, the comfort level of the developers with any given approach, or even the quality of available documentation. Which are all fair reasons, but neglect to mention the compatibility of the adopted approach to the issue at hand and fails to take into account all pro's and con's. And if the original developer was intimately familiar with all available approaches and had no technology bias, the selection may have gone differently and been quicker or produced a better result in the end.

And specifically addressing the requirements that you have quoted, JDE has sample XML "programs" to do this (and/or similar) stuff. Have you looked into that? Just curious. - it may have potentially proved to be quicker to develop, would have likely offered the same integrity and very probably resulted in a faster interface, not to mention no additional licensing requirements...
 
Just a point in here ... The AIS solution was initially tied to the mobile applications in E1. So leveraging an existing app with all the tested and proven logic but displaying on a device was great. Oracle ADF integration seemed to follow as the paradigm grew. I created a POC to display AB info on my Pebble watch (RIP), but it was pretty simple and more importantly, worked. My point is that this is just one integration option, to utilize existing full applications as APIs based on a UI. In some cases it may be great. In other projects, calling a BSFN is much more pragmatic and XML CallObject is the choice (DSI etc.). The "best" solution to any project is understanding all the options. I could see a complex integration using all the options in concert.

pardon if I simplify, again the code monkey disclaimer,
Craig
 
Last edited:
... not to mention no additional licensing requirements...

You need to be very careful with those sorts of statements Alex as that is fairly misleading and in most instances the licence impact of using XML, BSSV or AIS is the same.
 
AIS works a LOT faster than you're portraying. Try sending thousands of sales orders into AIS in parallel. It works exceptionally well.


Jon - I will get a benchmark on Journal Entry through AIS vs our product and post it here.

As promised, here are the results between AIS and LynX Business Integrator (LBI) for a 1,000 line Journal Entry. The Journal Entry had only two fields in the detail to make the payload as small as possible for AIS.

AIS: 255 seconds (average of 3 times)

LBI: 8.5 seconds (average of 3 times)


Just want to add some points:

* No other users on the system during the test.
* The AIS and HTML server are on a box that has 6.5 G of RAM. Both have 2 G allocated to them (JVM memory).
 
Last edited:
Russell,

Unless it's just changed, I don't believe so: AIS has a clear requirement to get Per Device licenses, plus it triggers Per Module licensing for all invoked APPL's. But XML API's do neither, I believe it uses the license of the executing JDE user, which would already be in place for that user.
 
I don't believe thats true Alex. AIS is just another delivery on top of JDE HTML - so it only requires a named user license for JDE. It doesn't need per-device licenses. I think you're thinking of the custom mobile ADF solution...
 
I was "told" that in an IoT type scenario, every device needs a named JDE user license. Otherwise, I could get away with just one named user for IoTs on my entire shop floor. I would confirm with Oracle as some of this may have changed.

.. no comments on the performance benchmark? I was accused of "devolving the thread" without facts to back it up.
 
I was "told" that in an IoT type scenario, every device needs a named JDE user license. Otherwise, I could get away with just one named user for IoTs on my entire shop floor. I would confirm with Oracle as some of this may have changed.
This is correct. Every device should have a named user license. But that is no difference in any respect to how you access JDE Logic. If there are many web users on a web page, and they trigger logic that communicates to JDE, then technically each user needs a named user license. You can try and fight it, but Oracle likes those kind of legal battles....!
.. no comments on the performance benchmark? I was accused of "devolving the thread" without facts to back it up.
Looks good. Though you're benchmarking AIS vs your own product. Initially we were talking about AIS vs BSSV - can you do a similar test with BSSV ? I would assume the difference would be less between AIS and BSSV, and greater with 3rd party products...?

What WOULD make a great presentation at a conference is a performance benchmark like this across ALL types of integration technologies. But not just a single 1000 line journal entry (which isn't common) - instead doing something like 1000 x 5line Sales Orders. Thats more real-world !
 
across ALL types of integration technologies

At some point I had plans of precisely doing this, but lost interest.

Initially we were talking about AIS vs BSSV

I don't have time or the interest to delve into BSSV. Besides, my expertise is in .NET and not Java. Based on integration architecture, I suspect that BSSV will only be marginally faster than AIS.

and greater with 3rd party products...?

Most 3rd party products use XML call object. Again, I don't have the time to do this - may be someone can volunteer to do this? Our product does not use XML call object - it is built from scratch. For something like a 1000 line journal entry, the XML request will be pretty large and it has the potential of crashing the XML call object kernel. The sales order scenario you suggested is a better candidate to test.


But not just a single 1000 line journal entry (which isn't common) - instead doing something like 1000 x 5 line Sales Orders.

If/when I get to this, I will let you know. I suspect that our product will still outperform AIS, but not by that much of a margin.


What I liked about AIS was the "briskness" with which it opens forms (assuming they have already been opened). However, there were some annoyances as well - 1) If I created a request with invalid data in the grid, I have pretty much start over (i.e. close the form and reopen it). If I fix the request send the same request over (as you normally would in an integration debugging scenario), it will simply add more data to the grid! I can, of course, send a request to delete/update the bad grid rows, but that is not part of the normal integration workflow. 2) Error Handling: Errors like bad account numbers etc. show up in the response, but I did not see how those errors co-relate to the input (may be I am not looking in the right place?). For e.g. if there are 5 lines and the 4th line has an error, there was nothing in the error to indicate that the 4th line had the error. In the normal E1 form, the field will "red out".
 
I can't be certain, but I thought with AIS this was triggered no matter what client was used...
 
But not just a single 1000 line journal entry (which isn't common) - instead doing something like 1000 x 5line Sales Orders. Thats more real-world !


This got me thinking .. I don't have to do wait to do a test specifically for sales order, I can do the same for journal entries 1000 X 5 lines instead of one 1000 line entry. In addition, we ran a test on a more common scenario - address book with supplier master (this is a smaller data set). Here are the results. .


GL Upload:
1000 documents with 6 lines each: AIS: 171 s, LynX Business Integrator: 65 s


Supplier Master:
100 records: AIS: 25 s, LynX Business Integrator: 9 s

  • With AIS, the performance is more or less proportional to the # of records. With LynX, we see better average performance per record for larger data sets.
  • The Enterprise server has 1/2 the memory and 3/4 CPU of the HTML/AIS server, and that's where the integrations run for LynX, so AIS has an advantage in this set up.
  • The IIS server (where the web service is running) has only 1/4 the RAM and 1/2 CPU of the HTML/AIS server.
 
With regards to licensing there are basically three options available (ignoring enterprise licensing agreements), irrespective of method used.

1. Full named user license - you have a full user license for the module/component being utilised as part of the interface. This user can also use the module directly through the JDE web interface.
2. Mobile user license - this license allows the user to use any module that you have at least one full named user license for. The user is not allowed to access JDE directly.
3. IoT Device License - this is basically 10 named user licenses for the price of 1. Simply put, Oracle defines a device as a client that interacts with JDE without direct user interaction.

Also be aware that there are a number of deals available from Oracle in this space if you purchase things like IoT Cloud and Mobile Cloud Service from them.

Another thing to note is that without IoT Orchestrator there is no way to define reusable REST services with AIS. IoT Orchestrator is a separately licensed product.

Obviously you need to confirm your specific licensing requirements with Oracle but that is the basics with regards to interfaces at the time of writing.
 
Last edited:
How on earth have I missed this thread :)

One of my goals for 2018......find new ways to talk to E1 over BSSV (Which I hate with a passion!)

Thanks folks
 
I've made an unholy combination of Javascript + Chrome + XML Call Object DLL's to deliver desktop applications that interact with JDE. There are some downsides to using the toolset but the end result is pretty slick, allowing you to execute SQL queries & JDE BSFNs with a few lines of Javascript. I use it to automate a few complicated business processes that are outside the reach of standard JDE development tools.

The initial build process is pretty complicated, but if you have web development skills then it becomes a really easy way to crank out quick & useful business automation.
 

Attachments

  • nwjs-jde.jpg
    nwjs-jde.jpg
    11.1 KB · Views: 39
Back
Top