Integration Comparison – When to use XML, API and JDF

This article is NOT for software developers – it’s for those of you who have a vision for an integrated workflow and want to find out a bit more about how to get started.

You may have your in-house technical resource to assist you, or you may have to bring in external support. Either way, you want to know about the different options available and which type of integration will help you achieve your vision.

Integration projects usually require you to take 2 or more software applications and make them talk to each other using one of the available protocols. But which one do you choose?

In the printing industry, there are a few widely accepted protocols that can be chosen - XML, API, and JDF. In this article, we'll explain the difference between them and suggest the situations that are most relevant for each one.

What is XML? 

XML stands for ‘eXtensible Markup Language’ and is commonly used to exchange information from one system to another.

It consists of defined elements and attributes which are usually appropriate for the relevant system. Sometimes the structure of these elements and attributes can be adopted as a standard and published.

Adopting an already agreed XML schema is much quicker than starting from scratch.

What does XML look like?

<CATALOG>

<BOOK>

<TITLE>Integration for a Digital World</TITLE>

<AUTHOR>Print MIS</AUTHOR>

<YEAR>Current year</YEAR>

</BOOK>

<BOOK>

<TITLE>Integration Checklist</TITLE>

<AUTHOR>Tharstern</AUTHOR>

<YEAR>{Current year}</YEAR>

</BOOK>

</CATALOG>

In what situations would you use XML?

In the printing world, it can be used to export transactions and import material stocks.

It’s also commonly used to integrate web-to-print software with an MIS solution, especially if the products are quite simple with a fixed manufacturing route.

In a practical sense, the end user places an order via a web-to-print portal and this is converted to XML and sent to the MIS, along with a URL for the artwork. The MIS uses the data to create a job, retrieves the artwork, and then attaches that to the job.  

The pros of XML

XML is a very flexible format and very powerful. It can describe almost anything and is a fantastically simple tool for achieving integration. The information you need to submit can be as little as Customer, SKU, Quantity, and Price for each line item. And if you’re using an already agreed schema (like cXML), the project will be even easier.

XML would be ideal for mundane tasks like monitoring and recording a piece of physical equipment. 

The cons of XML

XML’s simplicity can be a downside too. It typically works through hot folders and two-way validation is therefore limited. You're also set to a specific standard, and cannot work outside the box.

It also relies on both systems being synchronized which can often require complex mapping of elements and attributes between the two applications. If it’s not an already agreed schema then it could be a long and complex process.

How long will a cXML integration take?

If your MIS supports XML out of the box and you have the necessary expertise, you may be able to manage this in-house and you could be up and running in 2-3 weeks.

What is an API?

API stands for ‘Application Programming Interface’ and is a way for one application to interact with another application. Only the target application needs an API; a programmer (acting on behalf of Application A) will use it to request information from Application B and also instruct Application B to carry out actions on behalf of Application A, as per the diagram.

Generally, the programmer will start by getting a list of information that they can request from the target application, a set of actions that they can ask the application to perform, and details of how to ‘word’ each request. For example:

• Create a customer in Print MIS
• Set a milestone
• Create an estimate
• Return the details of that estimate back to the developer for use in another application

A budgetary consideration of API

It’s worth pointing out that you may have to pay a license fee for using an API, and there’s a very good reason for that. If a software provider has invested time and money into creating a product with comprehensive functionality, then allowing a third party to make use of this functionality for free would remove any requirement to buy their software.

Anyone with programming knowledge could just create a simple web-based UI that delivers all the same functionality, just by calling upon it with the API. The license fee is therefore required to protect intellectual property.

In what situations would you use an API?

This is a more powerful and robust integration than XML, gives you much more functionality, and is based on your business logic. You would use API if you want one application to make use of the functionality of another.

Here’s a couple of examples of how others have done that:

• Instant pricing – Infigo Software used our API to bring the full functionality of Tharstern’s estimating engine into their storefront portals. So the end user can create their own estimates and place orders, without having to pre-define these in the system using SKUs (as is the case with XML).
• Job tracking dashboards – One customer has written a dashboard to track jobs through production. Using the API, they retrieve job information from the MIS and use it to update a self-developed dashboard that reports on key KPIs in real time.

The pros of an API

An API is a more robust and powerful method than XML and you can use it to create bi-directional integrations. It removes the need to synchronize data across the two applications (as with XML) because all attributes are available to query. With an API, you can also customize and work more flexibly, and it's better for more creative work. 

The cons of an API

Using an API is more complex and requires more effort. So you will need to have development resources internally, or you will have to satisfy this need using third-party service providers. It’s also worth pointing out that not every application has an API, so this may not be an option for your project.

Typical timeframes for an API integration

The timeframe can vary dependent on the project, but could typically be around 2-3 months.

What is JDF?

JDF stands for Job Definition Format and is an agreed XML schema. It was developed by an organization called CIP4 to create a common language that would make cross-vendor workflow implementations easier.

While a PDF file describes the content of pages, a JDF file describes what to do with those pages. It contains all the information that operators in prepress, print-production, and post-press would normally need to know from a more traditional job ticket.

What is xJDF?

xJDF is simply an updated JDF format released from CIP4.

In what situations would you use an JDF?

You would use JDF to integrate your MIS with your production equipment, allowing you to pre-set job information within your production workflow such as prepress and press. Some examples include:

• Sending a job directly from the MIS through to prepress, including a detailed description of the prepress and press processes.
  
  
• Sending real-time job and device tracking data back to the MIS to facilitate job costing and analysis.

The pros of JDF

The technology is an industry-wide standard that has been around for 20+ years, so you will be able to achieve some form of integration with whichever vendor you choose. It's also very good for machine-to-machine connectivity.

The cons of JDF

Whilst it’s an adopted standard, the level of adoption varies between vendors, meaning you might not achieve the same level of integration with all your production equipment. JDF is also limited with variable data for digital products and is better suited to more simple products with not much variation.

Typical timeframe of a JDF integration project

JDF makes use of the ‘write once, use many’ approach, so this will vary depending on whether or not the connection has already been written. An integration using common production methods could be up and running in a matter of hours, but if your project has a larger scope than this, additional work will be required and the timescale will be longer.

Generally, most systems will be up and running in a few days, but will also be part of an ongoing integration project that will see the system evolve over time to give even greater automation.

In summary

Here’s a general idea of which method would be best for your integration project:

XML

• If your intention is to take the output from an online storefront and submit this to your MIS so that an order can be created, then we recommend you go with XML, as this is exactly what it was designed for.
  
  
• You could also use it to export transactions from your MIS into other applications and import material stocks into your MIS.

API

• If you need more control than XML can provide, and the application you want to connect to has an API, use it.
  
  
• If you intend to provide a bi-directional interaction between a website and the MIS, then the API is the tool for you.

JDF

• Use JDF if you want to integrate your MIS with your production equipment.

Our main piece of advice is to embrace as many options as possible and adopt a hybrid workflow; have the API at the front bringing the orders in, and JDF at the back running your production. 

We haven't yet reached the point of replacing JDF completely, but it's sensible to use the new technologies alongside it to strengthen your integration.