Integration Options - HTTPS Endpoint Preferred

Pierce911

Member
Thank you for everyone who contributes to this forum. I have spent a lot of time on here this week researching and am eternally grateful for all the talented people contributing their expertise to these discussions.

I have a client that needs to interface with some new warehouse automation hardware. The automation vendor has an interface that uses HTTPS endpoints (JSON). so clearly that is the preferred option for developing an interface. This interface will require sending warehouse data to the warehouse automation software (WAS) (calling their endpoint) and in other places receiving a notification from WAS when processing is done, request to print labels, etc. (them calling a new E1 endpoint).

Client is running 9.0 with tools release of 9.1.5.9, Enterprise Server is running on MS-Windows. No AIS or BSSV server is in use. They do use XML CallObject with ERP2WEB, which was recently implemented. They are a small shop, but highly customized in places.

AIS/Orchestrator
- Sounds like this would be the solution recommended by Oracle. Would create an HTTPS endpoint for the automation software to interface back into E1. Would require a license for Orchestrator. Would be reusable in the future for accessing E1.
- Can it call custom applications? Would I then have to basically write BSFN into a custom app, and mimic calls to that app, since it does not expose BSFN? This is only 1-way interface, correct? No way for me to send data to the WAS endpoint, correct? Looks like they would have to hire an expert to setup an AIS server, is this correct? Or is AIS setup easy enough for a developer to do following the guide?

3rd Party REST Integration Solutions
- I’ve looked at a few of these and they sound much easier to setup and they expose BSFNs directly, which would make interfacing back from the WAS very simple. Most of these appear to only create HTTPS endpoints and not to have an option to consume the WAS endpoints (one vendor I contacted had a tool for this). Of course, these options have a cost associated with them, which could be mitigated by saving development of a custom interface.

XML CallObject
- Could have WAS develop new custom interface back to E1 using XML CallObject. Would not require any new license but would entail custom development costs.

Sending Data to the new software
This brings up the issue of how to call the endpoints that WAS already has for interfacing data out of E1. I have read that this is possible with RTE or by using cURL. This would basically entail custom C BSFN development, correct? Are these the best ways to call the WAS endpoints and send my E1 data to WAS?

Am I understanding all of my options correctly? Anything I am missing?
 
Hari,

How does the outbound call work from within E1? I don't see anything about the outbound calls on the product page.
 
The outbound web service is called from a business process, which is written in .NET (this is a trivial task in .NET). See https://www.aellius.com/lynx-business-integrator/integration-development/ for details. All business process are exposed as web services. We provide business functions (part of the product) that allow you to call those web services and retrieve the output / errors from the web service. These business functions can be called from ER code anywhere in E1.

Let me know if you need more detail. Thanks.
 
Back
Top