Skip to content

External Integrations

##Content - Overview - Crystal Reports - SQL Server Reporting Services - Stream Serve - Generic


In some circumstances it might not be adequate to use the built in Report Designer to design and generate reports. We then have options to use 3rd party vendors to process and render the reports. It is possible to write new reporting plug-ins to cater for any such vendors, but we provide a couple of common options for our customers convenience. Currently we support rendering reports for:

  • Crystal Reports
  • Stream Serve
  • SQL Server Reporting Services
  • Generic

However, the integration with the above products differs from a technical perspective and various limitations apply. Please see more details of each product below.

Crystal Reports

The integration consists of a built in Crystal Formatter running inside the middle. Its only job is to call the externally installed Crystal Web Service (CWS). It is this CWS that contains the Crystal Reports runtime engine that is responsible for rendering the report, to which it requires a direct database connection. The resulting report is returned in a PDF format and will be automatically archived and passed to the standard report process. This makes the integration practically hidden from the end user. However, limitations apply for the designers of reports though. You must follow a set of guide lines and you can must get the data from the result set, which does not contain any custom fields.

This integration requires no separate 3rd party license for the customer to run, but the component CRYSTL has to be acquired.

SQL Server Reporting Services

This integration is somewhat similar to the one for Crystal Reports. Our SSRS formatter will make a web service call and receive a PDF back. But for SSRS you need to install a full SQL Server environment with SSRS attached. This means the customer has to pay a license fee to Microsoft. 
The integration is built as a report plug-in. The plug-in calls SSRS over a SOAP web service, sending the result key and a newly generated security token. The report is then rendered in the SSRS server which will call back to IFS via a set of web services called Report Data Services by using the token and result key. See the below picture to get a better understanding of the process. In the end SSRS will respond with the report in a PDF format. This PDF in brought in to the standard reporting process which allows it to be archived and printed. The integration is completely seamless to the end user but a bit more challenging to install. See the installation guide.

When developing layouts for SSRS you need the Visual Studio edition that comes with SQL Server called Business Intelligence Development Studio (BIDS) and you use a special IFS Report Data Extension to receive the report data. The data is report XML but it has been flattened so it fits in the SSRS flat dataset concept. See the development guide for further details.

Stream Serve

The stream serve integration is more crude than the ones above. You use a special plug-in that basically converts report XMLs to a special kind of XML. This XML in turn can be transformed with the Stream Serve style sheet (xsl) that you store as the layout for the report. The resulting file is then outputted to a folder for Stream Serve to pick up. The reason for the first step here is to keep backward compatibility with earlier integrations. You can basically reuse any stream serve style sheets you have used in the past.


For other vendors it is possible to pass IFS report XML directly or via transformation by using IFS Connect. Either you use the built in printers SEND_XML_TO_CONNECT or SEND_FULL_XML_TO_CONNECT or you use the Report Rule Engine to set up rules that trigger the integration. Output files can be either put in a folder, sent over FTP or emailed.

A more powerful way would be to develop a new report plug-in for the purpose.