Page 1 of 4 1 2 3 ... LastLast
Results 1 to 10 of 37

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 06:07 AM.

  2. #2
    Member craig_welton's Avatar
    Join Date
    Oct 2000
    Location
    Litchfield, CT
    Posts
    859
    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 07: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

  8. #8
    Senior Member altquark's Avatar
    Join Date
    Oct 2000
    Location
    Kansas City, MO
    Posts
    2,636
    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.
    Jon Steel
    EnterpriseOne/SOA Technical Architect
    erpSOURCING LLC
    http://www.erpsourcing.com
    cto@spla.sh
    24/7 Assistance - (904) 382 5701

  9. #9
    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?
    Regards,

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

  10. #10
    Senior Member altquark's Avatar
    Join Date
    Oct 2000
    Location
    Kansas City, MO
    Posts
    2,636
    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 !
    Jon Steel
    EnterpriseOne/SOA Technical Architect
    erpSOURCING LLC
    http://www.erpsourcing.com
    cto@spla.sh
    24/7 Assistance - (904) 382 5701

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.