Interface Portal FAQ

1. What does the Interface portal do that you could not or should not do with custom code?

If you create custom code:

  • You generally build only the business logic to process or generate the actual file;
    • no logging of file contents,
    • no logging when the file was processed or generated,
    • if errors occurred during file processing or file generation, you would have to search in the batch job history for the error,
    • there are no restarting capabilities in case file processing or file generation failed.
  • The field definition would be hard-coded, which isn’t the best way to manage your interfaces.
  • Each interface would have a separate menu-item in the menu; you would not have all interfaces in one place to manage.
  • In case of errors, there’s no mechanism to inform the users/administrators.

Interface portal:

  • Logs all messages that are processed and generated, including file contents, processing date/time, any errors that occurred during file processing or file generation.
  • Assigns a status to each interface run, the status can be changed from ‘unprocessed’ to ‘read’ in order to reprocess the file (without the need for the original file).
  • Allows developer/administrators to setup the file definition; column numbers, begin/end position, filler characters, field separator characters and mapping can be changed without having to do programming.
  • Manages all file and ADO.NET based interfaces in one single place.
  • Can send an e-mail in case of errors and has a dashboard that shows all interfaces that had issues during the last hour/day/week/month/year.

2. What are the main technical gaps in Dynamics that make Interface portal compelling?

Dynamics AX (DAX) comes with the Application Integration Framework (AIF) as its framework for integrations. The AIF can generate and deploy web services and create or process XML files.

Limitations of the AIF are:

  • No support for processing or creating text files.
  • XML files are generated based on a DAX query; they are a representation of the DAX data model. It’s not possible to change the arrangement of elements, change element names, add attributes, etc. In order to change the message, a middleware solution like BizTalk is required to reformat the XML or transform the XML to text.
  • Logging of the messages sent or received is a bit poor; the message status is registered, but it’s not visible to the user. Even though the AIF registers the exceptions that occurred during message processing or message generation, it does not relate the exception to the corresponding message.
  • AIF has no restarting capabilities when message processing or generation failed.

Interface portal:

  • Supports processing and creation of text files.
  • Can write to all data sources that support ADO.NET (i.e. a SQL server database).
  • Can process or create XML files in any format; the developer/administrator can setup any number of namespaces, elements and attributes. There’s no need for the message to reflect the DAX data model.
  • Has extensive logging capabilities; the interface history records the file contents, processing date/time, processing history (all past interface runs for a particular message), error logging.
  • Is able to change message status and reprocess or regenerate the message.
  • Is considerably less complex than AIF. The AIF requires a number of different objects (like a service class, document class, data contract class, AxBC class, query) to facilitate an integration. Interface portal requires only one interface handler class.

3. Does Crimsonwing have a unified standard approach for building integrations, including with Interface portal?

Dynamics AX (DAX) comes with the Application Integration Framework (AIF) as its framework for integrations. The AIF can generate and deploy web services and create or process XML files.

Limitations of the AIF are:

  • No support for processing or creating text files.
  • XML files are generated based on a DAX query; they are a representation of the DAX data model. It’s not possible to change the arrangement of elements, change element names, add attributes, etc. In order to change the message, a middleware solution like BizTalk is required to reformat the XML or transform the XML to text.
  • Logging of the messages sent or received is a bit poor; the message status is registered, but it’s not visible to the user. Even though the AIF registers the exceptions that occurred during message processing or message generation, it does not relate the exception to the corresponding message.
  • AIF has no restarting capabilities when message processing or generation failed.

Interface portal:

  • Supports processing and creation of text files.
  • Can write to all data sources that support ADO.NET (i.e. a SQL server database).
  • Can process or create XML files in any format; the developer/administrator can setup any number of namespaces, elements and attributes. There’s no need for the message to reflect the DAX data model.
  • Has extensive logging capabilities; the interface history records the file contents, processing date/time, processing history (all past interface runs for a particular message), error logging.
  • Is able to change message status and reprocess or regenerate the message.
  • Is considerably less complex than AIF. The AIF requires a number of different objects (like a service class, document class, data contract class, AxBC class, query) to facilitate an integration. Interface portal requires only one interface handler class.