Skip to content

Gathering Requirements

Important Questions

Important questions to seek answers to when designing an integration include:

  • Is there a middleware or enterprise service bus, such as Dell Boomi, which can handle message transformation and queueing etc.?

  • What data formats does the other system(s) handle? Can they adapt to IFS out-of-the-box JSON and XML formats? If not, what types of data can be handled?

     -   JSON

 -   XML

 -   CSV

 -   Flat files

  • What transport protocols can the other system handle?

    -   SOAP Web services over HTTP with SOAP/XML message format

-   Restful services over HTTP with JSON, XML message formats

-   File transfer over SFTP or FTP

  • Are there specific data translation requirements (e.g.: IFS and external system using different supplier id or part numbers, etc. that need to be cross-referenced), and if so, can they be handled in middleware / service bus?

  • What is the frequency? 

     -   One-way periodical batch transfers

 -   Asynchronous messaging (compare with voice mail and call back)

 -  (Near) real-time synchronous messaging (compare with phone call)

  • What are the expected data volumes?

  • Are there any specific monitoring requirements? 

     -   Can monitoring be external e.g. in middleware/service bus?

 -   Is it sufficient to monitor Application Messages in the IFS Solution Manager?

 -   Is additional logging, reports or screen/pages for monitoring required in IFS?

  • Are there any specific error handling requirements? 

     -   Can errors from IFS be synchronously returned to the calling system?

 -   Is it sufficient to capture errors for outgoing Application Messages in the 
     IFS Solution Manager?

  • Are additional screen/pages for handling and editing of inbound or outbound data required (compare with e.g. Incoming Customer Orders and External Invoices in IFS).

  • Are there any special encryption requirements? 

    -   Is the usual out-of-the-box HTTPS/SSL encryption sufficient?

-   Are there special encryption requirements such as PGP?

  • Does data exchange with the external system require a sequence of related messages back and forth that forms a ‘conversation’?

Additional Effort

Note that requirements that quickly can lead to additional effort and cost include:

  • Additional error handling features in IFS

  • Additional monitoring features in IFS

  • Data translation and transformation handling in IFS

  • Handling of synchronous message responses from other systems in IFS

  • Large data volumes, requiring substantial performance tuning

  • Integrations requiring special setup e.g. for file transfer in cloud hosted environments.

  • Authentication

    • Access to external endpoint to exchange data can get complicated. It is important to understand what authentication model need to be followed in order to gain access to the external resource.

Granularity of Messages

Another aspect to consider is the granularity of messages:

  • APIs designed primarily for system-to-system type integrations can be “coarse grained”, asynchronous, and built according to service-oriented principles (SOA). A simple structured JSON message can be received with the complete supplier information including addresses, contact information and company/invoice specific data etc..

  • The RESTful APIs used by IFS Cloud Web on the other hand are synchronous and atomic. Separate calls would be needed to create the supplier master record, each address and contact etc. These are primarily designed for user interaction, but can of course be reused for integration, more easily if there is a middle ware such as Dell Boomi that can handle data transformation.

  • In IFS Cloud it may be possible to reduce the number of required calls using the Business Process Automation.

  • In IFS Cloud the BizAPIs have been replaced with structured integration REST APIs. Such APIs can also be developed on IFS Applications 10. They are modelled in Marble, and generally easier to design and develop than the legacy BizAPIs.