Advantages and disadvantages of each connector
Using the Infor Application Connector is preferred, because it is decoupled and event-driven, and the application can validate the correctness and consistency of incoming data. From a modeling and management perspective the Infor Application Connector also is the best choice, because the modeling is very simple and the management in ION Desk is the richest for this connector.
If you cannot use the Infor Application Connector, you can use the following sequence as a rule of thumb to select one of the other connectors:
- Message Queue Connector
- Web Service Connector
- File Connector
- Database Connector
This table shows advantages and disadvantages of the individual third-party connectors:
| Connector | Advantages | Disadvantages |
|---|---|---|
| Message Queue (JMS) | Event-driven solution, so it closely matches the ION architecture. | The message queue only provides a technical communication channel. Behind the message queue the messages must be created or processed. If the message is not a BOD, it must be transformed. |
| Web Service | No change required in the application, existing web services can be used. | In the model you must transform the messages from BOD to web service input and from web service output to BOD. Existing web services often do not offer operations to retrieve only the changed objects. Transactionally less robust than database or message queue connector, so higher risk or delivering the same message twice in case of interruptions or timeouts. |
| File | Suitable for legacy applications that only support a file-based integration. Event-driven. | The application at the other side must be in a position to create files in a format that ION can process or read files as provided by ION. The data must be transformed to a BOD (XML) message. Multilevel data (header and lines) can be formatted in multiple ways in one or more files, while the File Connector does not support all options. Transactionally less robust than database or message queue connector, so higher risk or delivering the same message twice in case of interruptions or timeouts. |
| Database | No change required in the application (except the addition of stored procedures in the database schema). | Risk for data integrity, because you bypass the application that owns the database, while updating the database directly. You must write stored procedures to query the database and transform the result to XML or to retrieve the data from the incoming XML and update the database . These procedures can become complex when handling multi-level objects (such as headers and lines). Additionally these procedures will be database-dependent. Not event driven. The database must offer data to retrieve the new or changed data, such as log tables. Timestamps can be used for new data, but will not expose all intermediate changes that occurred between two scheduled read actions. |