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 own 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.
This article aims to explain the difference between them and suggests the situations that are most relevant for each.
XML stands for ‘eXtensible Markup Language’ and it 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. For example, Tharstern has adopted the cXML e-commerce format to submit orders from a web-to-print storefront into its MIS. Adopting an already agreed XML schema is much quicker than starting from scratch.
<TITLE>Integration for a Digital World</TITLE>
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 manufacture 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.
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’s simplicity can be a downside too. It typically works through hot folders and two-way validation is therefore limited.
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.
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.
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 on the right.
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 an example, see Tharstern’s here). Some examples of what you could ask Tharstern to perform are:
It’s worth pointing out that you may have to pay a licence 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 licence fee is therefore required to protect intellectual property.
This is a more powerful and robust integration than XML and gives you much more functionality. 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:
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.
Using an API is more complex and requires more effort. So you will need to have development resource 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.
The timeframe can vary dependent on the project but could typically be around 2-3 months.
JDF stands for Job Definition Format and is basically 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 postpress would normally need to know from a more traditional job ticket.
If you want to read a bit more about JDF (in plain English) then this article from our MD is a really interesting read.
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:
The technology is an industry-wide standard, so you will be able to achieve some form of integration with whichever vendor you choose.
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 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.
Here’s a general idea of which method would be best for your integration project: