Results 1 to 7 of 7

Thread: E9200 Integration Options

  1. #1
    New Member cmisztur's Avatar
    Join Date
    Feb 2017
    Location
    Chicago
    Posts
    4

    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
    Last edited by cmisztur; 02-17-2017 at 07:07 AM.

  2. #2
    Member craig_welton's Avatar
    Join Date
    Oct 2000
    Location
    Litchfield, CT
    Posts
    800
    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
    Last edited by craig_welton; 02-16-2017 at 08:14 PM.
    Craig Welton
    PatWel Group Inc.
    http://www.patwel.com
    Home of the FREE JDE Object Browser, JDETrace and NERDup Tools

    E1 9.0 8.98.3 iSeries
    E1 9.0 8.98.4.2 Wintel SQL 2008

  3. #3
    New Member cmisztur's Avatar
    Join Date
    Feb 2017
    Location
    Chicago
    Posts
    4
    Thanks, errr, not sure what happened but my original post is missing. Looks like I broke the forum.
    Chris Misztur | http://mriiot.com

  4. #4
    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.

  5. #5
    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/showthre...ng-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.
    Regards,

    Hari Sharma
    Aellius
    EnterpriseOne: Integration (.Net, Web Services) | Output Management | Monitoring

  6. #6
    Quote Originally Posted by cmisztur View Post
    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.
    Russell Codlin
    www.rinami.com
    Capital Asset Management & Manufacturing Specialists
    REST Integration, IoT, Mobile Applications and Job Scheduling for all E1 releases from 9.2 back to 8.11SP1

  7. #7
    New Member cmisztur's Avatar
    Join Date
    Feb 2017
    Location
    Chicago
    Posts
    4
    Quote Originally Posted by jdelisths View Post
    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/showthre...ng-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
    Chris Misztur | http://mriiot.com

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
The legal restrictions and terms of use applicable to this site are available here.
Use of this site signifies your agreement to the terms of use.
JDELIST is NOT affiliated with JD Edwards® & Company, Oracle or Peoplesoft. Contents of this site are neither endorsed nor approved by JD Edwards® & Company, Oracle or Peoplesoft.