E9.2 Digibee vs. Mulesoft

MonsterCable

Active Member
Has anyone worked with and built integrations with either Digibee or Mulesoft? Any takeaways or feedback that you could provide?

We've had meetings with Mulesoft and are interested in other Integration options. We're trying to focus in on what platform besides Orchestrator could be our long term integration tool. We're expecting the solution to have full integration and flexibility in the future. Trying to figure out what Digibee can offer that Mulesoft can't. Or is there another solution that exists out there that we should be looking into?

Thanks.
 
We have a customer using our EveREST2JDE with Mulesoft in Canada, have been using it for over a year now.
 
I can attest that the Everest products I've used have been good fits. And support was top notch.

Note: I am now retired, and don't have a horse in this race.

Tom
 
I'm a bit confused. Why would we need an additional application on top of Mulesoft? Shouldn't Mulesoft be able to do all the integrations we would need between E1 and any other application(s)?
 
What capabilities does Mulesoft have, specific to E1 integration? What method does it use to integrate with E1? That will guide you in the right direction (regardless of the middleware you choose).
 
I'm a bit confused. Why would we need an additional application on top of Mulesoft? Shouldn't Mulesoft be able to do all the integrations we would need between E1 and any other application(s)?
Mulesoft (or any other generic middleware solution) make use of connectors to integrate with specific solutions. So there are generic connectors like REST, JMS or FTP and then there are application specific connectors like Saleforce, ServiceNow or SAP. So the challenge with integrating to E1 is that it breaks one of the key tenants of good software design, which is separation of concern. Basically, due to the way that it was ported from World RPG over to OneWorld C code, a lot of application logic was embedded in the UI and this makes integration very difficult. This is why JDE integration has always been a moving target with OneWorld and no specific technique has really stuck. It is also why the Orchestrator/AIS works the way it does. At its most basic level, AIS is just a HTML screen scraper that interacts with the JDE UI. There have been features added over time but fundamentally, when you call a "form" you're interacting as if you were a browser.
So to the theme of your original question. Whether you choose Mulesoft, Digibee, Boomi, AWS or Perl Scripts will be based on factors other than how they integrate with JDE, because out of the box, none of them do. Hence why other solutions exist specifically for that problem.
 
Mulesoft (or any other generic middleware solution) make use of connectors to integrate with specific solutions. So there are generic connectors like REST, JMS or FTP and then there are application specific connectors like Saleforce, ServiceNow or SAP. So the challenge with integrating to E1 is that it breaks one of the key tenants of good software design, which is separation of concern. Basically, due to the way that it was ported from World RPG over to OneWorld C code, a lot of application logic was embedded in the UI and this makes integration very difficult. This is why JDE integration has always been a moving target with OneWorld and no specific technique has really stuck. It is also why the Orchestrator/AIS works the way it does. At its most basic level, AIS is just a HTML screen scraper that interacts with the JDE UI. There have been features added over time but fundamentally, when you call a "form" you're interacting as if you were a browser.
So to the theme of your original question. Whether you choose Mulesoft, Digibee, Boomi, AWS or Perl Scripts will be based on factors other than how they integrate with JDE, because out of the box, none of them do. Hence why other solutions exist specifically for that problem.
We did a demo with Mulesoft and they showed us their integration works at the kernel-level and uses REST calls.

I guess that's why I'm confused. On one had Mulesoft is telling us that they can do JDE integrations on the other hand, on the forums people are saying that not only would we need Mulesoft, but we would need additional software in order to make the integration work.
 
Can you post a link of the description of their connector that does this "kernel-level" calls? The REST calls, if they are not using AIS is probably a layer on top of the "kernel-level" calls.
 
Can you post a link of the description of their connector that does this "kernel-level" calls? The REST calls, if they are not using AIS is probably a layer on top of the "kernel-level" calls.

Sure. This is what I got from them:

PortX (Anypoint) JDE Connector serves as a JDE Dynamic Java Connector to communicate directly with the JDE Enterprise (see diagram below). There are two functional components within:
1) JDBC driver to obtain only metadata information form the JDE DB Server and JDE Net Socket
2) JDE Net socket access to execute the BSFNs within JDE and pass the XML data object.


Does that help? Or do you need more info?
 
That helps. Thanks. Based on this (and other documentation I have seen), they are using XML Call object (or an enhanced version of it), which means the functionality is limited by the what XML Call object can provide. To my knowledge (others - please offer corrections), it boils down to calling business functions and list operations (select on tables and views).

Our product (LynX Business Integrator) offers more functionality than this. DM me if you need more information
 
PortX (Anypoint) JDE Connector serves as a JDE Dynamic Java Connector to communicate directly with the JDE Enterprise (see diagram below).
I'd suggest you get a few references from Mulesoft from customers that have done some real world integrations with JDE using that connector before you jump in.
 
That helps. Thanks. Based on this (and other documentation I have seen), they are using XML Call object (or an enhanced version of it), which means the functionality is limited by the what XML Call object can provide. To my knowledge (others - please offer corrections), it boils down to calling business functions and list operations (select on tables and views).

Our product (LynX Business Integrator) offers more functionality than this. DM me if you need more information
> functionality is limited by the what XML Call object can provide

Can you provide more context on this? On the Mulesoft demo it looked like they had a component that could dynamically evaluate business functions & UBEs. I have a data sheet that Mulesoft provided where they've partnered up with Modusbox to provide their current E1 integration solution.

Here's a summary some things from the data sheet:

Key benefits:
  • 3x faster gaining access to E1 server directly
  • JDE functionality (BSFN, UBE, Outbound Events, Web-Services exposed by JDE)
  • Reuse standard business logic from JDE & your custom development
  • Can drag, drop, & deploy
Typical Use Cases/Operations:
  • EDI for Sales Order Management, Procurement, Inventory Management, Accounts Payable, Accounts Receivable, & Demand Scheduling
  • Dashbaords, Database Synchronization, & Data Transfer
  • Financial Connectivity Service (Journal Entries, Exchange Rates, Accounts Payable & Accounts Receivable information)
  • Inventory Connectivity Service (Pricing, Inventory Look ups, Picking, etc.)
  • Manufacturing Connectivity Service (Warehouse automation)
JDE Connector permits access to the business logic in E1 for all supported transactions - both BSFN & UBE

What I'm trying to understand is beyond the functionality above, what things specifically would Mulesoft not be able to do without LBI or another E1-specific integration tool?
 
LBI can do all table operations (including update and delete) through the JDE application layer (i.e. without having to directly access the database), with transaction control across business functions and table i/o. It can also do outbound web services (i.e. calling web services from a JDE app). You also get much better performance compared to other integration methods. Here is a demo of a 10,000 line journal entry in just over a minute:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
 
Back
Top