E9200 Integration Options

[cmisztur]

E920 Integration Options

Hello. I am a .NET developer trying to fit in the JDE world . As we move away from our ancient ERP systems and standardize on JDE we are looking for integration options.

Our first attempt has been the JDE-EO adapter within BizTalk. The Java Connector has not been as reliable as we would like it to be and this is what prompted me to dig into the available technologies.
We have evaluated Magic xpi, which I really do like as an alternative to BizTalk, but again Java Connector is used.

What has been reliable in production is the COM Connector. We have RFSMART and they use xmlinterop.dll to execute their XML call objects. So I am basing the reliability of the COM Connector on the past several years of solid performance.

Last year at the Vegas conference I saw a presentation on the IoT Orchestrator. The JDE dev that I was with said it was nothing more than a glorified UBE calling mechanism. Overall I was very disappointed with Oracle for abusing the "IoT" term.

I was then made aware of BSSV and was told that it is a good SOAP solution for calling vanilla BSFN, but no 55s could be called.
At the same time I learned about RTE, which would be awesome for our custom CRM in the pipeline.

One thing I have not dug into yet is AIS.

And then there is Eversoft and Aellius, which both look like they have some nice tooling.

In the end, we are looking for long-term:
* invocation of BSFN from external systems
* ingestion of RTE outside of JDE

Simple, right?

I appreciate any opinions you might have from your personal experiences!

Thanks
Chris

ref:
[1] EnterpriseOne Connectors Guide 8.9 PeopleBook
[2] JD Edwards EnterpriseOne Tools Interoperability Guide

 

[craig_welton]

If you are just looking to call JDE BSFNs from external app, I would suggest XML Call Object. It's the simplest. Just create the XML document and send with win32 or java API. If you need more complicated interfaces, AIS is strong (think screen scraping or remote controlling a JDE app). BSSV can be robust but can involve more development on both sides plus infrastructure setup.

just my input, I'm a code monkey. others may have more insight

Craig

 

[cmisztur]

Thanks, errr, not sure what happened but my original post is missing. Looks like I broke the forum.

 

[mdalton]

I'm a big fan of AIS. In load testing high volume transactions we're seeing an average of 2.39 records loaded in one second. I love that AIS makes any JDE application API consumable. BSSV was necessary at the time, but the ESB model is eventually going away. I can't believe that more companies aren't using AIS.

 

[jdelisths]

I want to add a few points about Aellius (LynX Business Integrator) here:

For inbound integration, Bsfns, table i/o and media objects can be called directly through REST, so no additional development is required.
For outbound integration, web services can be called directly using C# (no Java, BSSV, package builds etc) and they can be invoked directly from E1 from ER code (we have custom business functions to do this).

While AIS is a good option, it is not true integration in my opinion. It is essentially a screen scrapper as Russell pointed out in this post: https://www.jdelist.com/vb4/showthread.php/51258-BSSV-using-REST-in-JDE.

Filling up controls in a web form and "clicking OK" is not true integration. Consider this: Our product can create a 1000 line journal entry in less than 10 seconds. If you cut-and-paste it in E1 (or use AIS) it takes at least 2 minutes. During these 2 minutes (or more), the HTML server is essentially at close to 100% CPU and other users see performance degradation. A 10,000 line journal entry WILL crash your HTML server. Our product does this in about 90 seconds. See for yourself on our YouTube channel: https://youtube.com/user/aelliuslynx.

 

[RussellCodlin]

Our first attempt has been the JDE-EO adapter within BizTalk. The Java Connector has not been as reliable as we would like it to be and this is what prompted me to dig into the available technologies.
We have evaluated Magic xpi, which I really do like as an alternative to BizTalk, but again Java Connector is used.

What has been reliable in production is the COM Connector. We have RFSMART and they use xmlinterop.dll to execute their XML call objects. So I am basing the reliability of the COM Connector on the past several years of solid performance.

XML Interoperability is very stable once you get to about the 8.98 tools and can be utilised from either .NET or Java perspective. We have large customers connecting through Java without any reliability concerns. This is somewhat different to the actual Java and COM connectors which are pretty much retired.

Last year at the Vegas conference I saw a presentation on the IoT Orchestrator. The JDE dev that I was with said it was nothing more than a glorified UBE calling mechanism. Overall I was very disappointed with Oracle for abusing the "IoT" term.

That's a fairly misleading representation of IoT Orchestrator. IoT Orchestrator really serves two purposes. In terms of the IoT part, it has the ability to filter and route messages coming in. This means that if you have monitors etc generating large volumes of data you can ensure that only messages that are relevant to JDE get through. Remember, JDE is not designed as a type of SCADA historian system so you don't want everything that machines spit out being consumed. The orchestrator part allows you to basically build AIS scripts that can be executed as a single call. One point to consider is that AIS is included in the base tools where as the IoT Orchestrator is a separately licenced product.

I was then made aware of BSSV and was told that it is a good SOAP solution for calling vanilla BSFN, but no 55s could be called.
At the same time I learned about RTE, which would be awesome for our custom CRM in the pipeline.

This is incorrect, 55 functions can certainly be exposed through BSSV but the effort required to develop BSSVs is relatively high compared to other options.

One thing I have not dug into yet is AIS.

If you're on a tools release after about 9.1.5.3 then you definitely should. It is now the Oracle JDE team's preferred method of integration and is getting a lot of development focus. When it first came out it was just a web screen scraper but lots have changed since then. The biggest problem with it at the moment is that if you don't have the IoT Orchestrator then it doesn't really provide a way to create reusable services unless you put some other middleware product in front of it. The other issue is that is doesn't provide (last time I checked) a way to execute BSFNs. This is the realm of the other connectors.

And then there is Eversoft and Aellius, which both look like they have some nice tooling.

In some respects these are competing products to ours so no comment I will say that we also provide a REST service publishing solution that makes use of a number of connection technologies including AIS and XML Interoperability.

In the end, we are looking for long-term:
* invocation of BSFN from external systems
* ingestion of RTE outside of JDE

Simple, right?

Point one is simple, RTE is a bit more involved and you need someone with experience in this technology to get it operating. Generally speaking you're going to need some Java middleware in the mix with RTE to get the best results so that you can have JMQ set up properly. If you don't have a strong requirement for real time data synchronisation you may be better looking at simpler approaches that have you consuming data out of JDE rather than trying to push it.

Final tip, include your JDE release, especially tools, in your signature so we know the options you have available. There is a massive difference between 9.1.4, 9.1.5, 9.2.0 and 9.2.1 tools so options and suggestions will change depending.

 

[cmisztur]

While AIS is a good option, it is not true integration in my opinion. It is essentially a screen scrapper as Russell pointed out in this post: https://www.jdelist.com/vb4/showthread.php/51258-BSSV-using-REST-in-JDE.

I have since been reading up on AIS and right, it sounds like more of a browser unit testing framework that I used in the past.

I kind of think that the formservice could create some nice competition to RFSMART and DSI approaches of data collection on the shop floor.

/c

 

[altquark]

AIS is definitely the future. It requires less development skills than other integration types - as you expose a web-form (eg, P4210) through the development tool, and "map" the fields you want to expose as a service. The only drawback currently is that AIS will only expose JDE processes as a service - it doesn't have the ability to CALL a service provided by a 3rd party application. But 90% of customers want to use JDE as the "source" - ie send data INTO JDE. AIS is incredibly easy to set up and configure (it can be installed on any JDE HTML Server). It might be a "screen scraper" technically - but its a very good methodology for integration - as ESU's that modify business functions will not alter how the integration works (unlike BSSV). BSSV developers will always be biased - as directly integrating to a Business Service will technically be faster since the overhead of the HTML Client isn't being used, but AIS works extremely well and scales well too.

 

[jdelisths]

as ESU's that modify business functions will not alter how the integration works (unlike BSSV)

BSSVs and other integration options like XML call object and our native .NET integration (LynX) will continue to work if ESUs modify business functions. If the data structure is changed (usually elements are added), BSSVs may fail (I am not 100% sure, but I have heard reports of this), but XML call object and LynX will continue to work.

If ESUs are applied to the form itself, then what Jon says is true - AIS will simply reuse that logic, but your integration may/may not require this new logic.

but its a very good methodology for integration

I respectfully disagree, Jon. Consider this scenario: You want to send emails through Gmail. Gmail does expose any native API to directly send email (assume that SMTP does not exist) and all that code is buried in their web forms. Then Google comes up with a brilliant idea: Just open a web session, fill in the fields (to, cc, bcc, subject etc.) and click the send button and makes this REST-enabled. Is this true integration?

 

[altquark]

Hi Hari

Actually, I didn't want to get into a "BSSV vs AIS" religious war. I just wanted to point out that creating integrations with AIS is a lot simpler than creating with BSSV. It might not be as "light" as the BSSV integrations or through other types of products such as your own, but the effort of Oracles JDE team to try and reduce development skill requirements through their "Community Developer" strategy is a noble one.

There will always be a need for true integration tools and true development methodologies, and there are places for that - but in my opinion, AIS provides something thats as "easy" as a flat-file integration thats real-time. If not easier.

Many companies have large back-logs of development work, and not enough development skills to answer all the requirements. AIS is one feather in a bow that includes UX-One and OneView that helps companies resolve a lot of the mundane development work quickly through "power-user" skills. And thats a major, major advantage over ANY ERP competitor. And any advantage that help sells the product is good.

But as I said, everyone is entitled to their opinions. But lets hope that the fact that AIS is present will help companies buy the product, because more companies = larger market share = more JDE all around !

 

[BOster]

Good points by both Jon and Hari. However, I tend to agree more with Hari on this. I don't have issues with AIS in and of itself other than it does seem like everyone, including Oracle, looks to it as THE interop solution of the future. My issue is that AIS is basically a "bailing wire and duct tape" solution born from years and years of bad application design/architecture (Business/Service Logic in the presentation tier) and just promotes more of the same. I wish Oracle was putting more effort into giving us better tools to build things like BSSVs (giving the option to build RESTful BSSVs) or other tools to build Web Services that don't require some glorified screen scrape technology - AIS simply smells of kludge.

I love the C language and I love writing C BSFNs but I am shocked that I still am writing C for business logic. 10 years ago I would have sworn that we would be creating "BSFNs" in Java by now. I thought BSSVs were going to be the bridge or the first step to get us there. First as an interop solution and hopefully later as an easy way to consume BSSVs (or some middle tier Java based service layer) directly from ER code (or hopefully other APPL/UBE "language"). I just hate too see something like BSSVs that is actually architected some what correctly not further developed due to all attention and resources given to something like AIS.

 

[brandonkirsch]

JDE contains too much business logic in the presentation layer. As such, AIS is a very good compromise when it comes to making 20+ years of JDE interactive apps available by API. It is not going to be the fastest, but it is a nice way to avoid duplicating code. Paying a developer to re-implement features that already exist is an expensive way to go.

I am still a big fan of the JDE XML API for its performance & simplicity. Just last week I figured out how to invoke JDE BSFNs from Javascript and will be releasing a free library for it soon.

 

[Alex_Pastuhov]

Interestingly, JDE provides a way to do complex interfacing with just XML: they support a complex XML format with variables, error handling, code forking and multiple BSFN calls passing parameters to each other, plus built-in transaction support. There's some doco available from Oracle on this syntax too. Such XML calls do not have any licensing implications, so there's clear savings here compared to either BSSV or AIS. And our EveREST2JDE middleware offers REST interface to this functionality as well.

So basically, the "programming" part with this approach can be done using this extended JDE XML syntax, it can be submitted to JDE through an easy to use REST front-end interface and the end result can be almost as complex as running an APPL through AIS. The difference is that with a ready APPL you just need to figure out the forms and the fields and with this extended XML you would need to reverse-engineer the business logic and program it into XML as a series of BSFN calls, but it would run a lot faster. Which all boils down to how complex the logic here is: it may not be practical trying to replicate a complex APPL logic splitting it into single function calls, but for many simpler processes the AIS with it's "screen scraping" would look too heavy and convoluted instead...

Just my 2c ;-)

 

[jdelisths]

Jon said:
Actually, I didn't want to get into a "BSSV vs AIS" religious war

I don't want to start a religious war either. Just want to present facts as objectively as possible.


I want to add a few points on AIS:

* AIS is not a good option for "proof-mode" integrations. We have several integrations which are called to simply validate the data (a Voucher with header, pay items and GL account lines, for example). This is something you cannot do with AIS. You have to commit the transaction by clicking OK and submit another request to delete what you just did, not to mention the waste of batch numbers and document numbers.

* Transactions that require multiple forms have to be carefully crafted to call multiple forms in the correct sequence and checked for multiple errors (this can be a major PITA). An example of this is Address Book. In our product, we have a single business process to create multiple address / customer / suppler master records in one go. To rebuild this in AIS, I have to make at least 10 form service requests for one record! And forget about the proof mode concept.

Brian said:
but I am shocked that I still am writing C for business logic

C/C++ still rules. Those are the true cross-platform languages out there - everything else like JVMs, .NET CLR are layers built using C/C++ to allow developers to use easier languages like Java or C#.

 

[craig_welton]

I look at this way ... each integration method has it's strengths and you can choose the one that fits. The cool thing is that we have several to choose from.

Craig

 

[altquark]

I look at this way ... each integration method has it's strengths and you can choose the one that fits. The cool thing is that we have several to choose from.

Yes. Absolutely. Its good to know that there are many different methods out there, and the limitations of each.

 

[Godino]

Hi Chris

Here you have an option

http://www.modusbox.com/2016/09/jd-edwards-connector-for-mulesoft-v1-1-1-release/

You can see how easy is create a connection to JDE.

http://www.modusbox.com/2015/12/extending-jd-edwards-for-the-mulesoft-anypoint-platform/

Regards

Javier

 

[Alex_Pastuhov]

Just thinking about different integration project sizes, very small-scale projects are often overlooked.

Consider the attached image - it's an example of how a bit of real-time JDE data can be plugged onto an intranet webpage with ~30 lines of PHP code (or ASP, etc.) in about 15 minutes, when your integration platform allows for such small tasks. I guess with AIS or BSSV, this would have to take days to do ;-)

 

[mdalton]

I think most people diminish AIS by calling it a screen scraper. AIS exposes the business logic of the application that you are invoking. Going through a traditional route of calling individual functions is effectively eliminated in a simple call to an orchestration. Oracle has invested well deserved effort in optimizing the control logic, rules engine and returned data sets. In our testing of AIS we have been able to process over 10,000 unique sales order transactions with an average HTTP request / response time of 1 record every .893 seconds. That is remarkably fast.

The new functionality that is being released are not trivial and indicate a very serious dedication amongst Oracle to enable JDE to operate as a platform. Look at how AIS is capable of doing with direct data access, querying, aggregation, currency support etc...

Look Oracle enabling innovation with JDE by encouraging consumers to have direct access to the data. This is a major point, as anyone who is an SAP shop can tell you. See here for the chaos that SAP has released with "indirect access" to data within SAP. http://www.computerweekly.com/news/...SAP-against-Diageo-in-indirect-licensing-case

Oracle is going in the opposite direction. You can use any language to invoke JDE and access the data. Calling AIS a screen scraper is just not giving the technology its' fair shake.

 

[jdelisths]

In our testing of AIS we have been able to process over 10,000 unique sales order transactions with an average HTTP request / response time of 1 record every .893 seconds. That is remarkably fast.

So, that works out to 8,930 seconds for 10,000 sales orders? Not sure what you mean by "transaction". Is one transaction = one sales order? Or is it 10,000 total F4211 records?