In this guest blog with us Dan Hudson, President of E-Spec, elaborates on his previous blog with us; here, he expands on exactly how to approach a PLM integration with Adobe Illustrator.
After my last article, “PLM Integrations with Adobe Illustrator – Keep It Simple”, I have been asked to expound on the correct simple approach. Our experience is that when the integration is too specific or customized to one particular business system, it limits the user’s flexibility when providing similar content to other destinations. Creative users do not live in a single system vacuum; their content can be used and re-purposed by many other people and systems within the enterprise.
Our integration approach is based on:
- Industry standard metadata
- Industry standard API’s (usually RESTful but previously SOAP)
- Separating multiple assets from a single file
- Tools to configure/map the metadata and API’s without programming
- Reusable tools – not customized per system, customer or particular installation
First – Identify Attributes
The first step is to identify the attributes that define a unique item (product, asset, object, style, etc.). In most of our customers, this is Style # and season; sometimes Style #, color, season, size or size range. The combination of these values will identify a unique record in all systems across the enterprise. Associating an image to these values enables the image to be linked to multiple systems.
Other attributes also need to be identified; the taxonomy and vocabulary of the enterprise. This is an exercise in determining the proper nomenclature, knowing what each system calls every attribute. This will allow information to be exchanged between systems.
Creating Metadata Fields
We provide our customers with a tool to create the metadata fields. We use Adobe’s XMP metadata standard to create custom XMP fields; these can be text, memo (multi-line text), date, combo boxes (pick lists) and check box fields. The field definitions look very similar to XML.
We provide a series of tools that can be configured by the customer to match their requirements. Our metadata collection tools are configured per user/user group. Each configuration is designed to minimize keystrokes for the user. Only the fields the user is concerned with are included. Where possible, default values are assigned to reduce data entry. We collect the metadata as the image is created, embedding the unique identifying data inside the image file. Additional descriptive or informational metadata can also be collected and saved in the file.
Separate Multiple Images
An additional tool is used to separate the multiple images that are contained in a single file. These images are typically separated by layer/sub-layer or by artboards. These derived files will also have the same metadata embedded in them as the original file has.
For systems that “catalog” files (like Digital Asset Management systems), this is enough as these systems will read the metadata and import it with the image into the system. For other systems we provide tools that will write the metadata and the image (or image path) directly to their database. If the database is proprietary or encrypted, we provide tools that will communicate with the system’s API’s to allow the metadata and the image to be imported into the system.
To help automate the integration, “target” locations (folders) are used. Most companies already have something similar in place; users have their individual work areas to store their working files and when the files are ready to enter the workflow, they are saved to shared locations so others can access the files. These shared locations become our “targets”. When a file is saved (or updated) in a target destination, the metadata dialog is displayed and all required fields (typically the unique attributes) must be provided. The file is separated into its individual images and the files routed as defined in the configuration.
Unique Approaches by Companies
Different companies use these tools to solve their unique integration challenges in different ways. One company uses this approach to tie their Illustrator files to the BOM maintained in their ERP system. Another separates the images into both JPG and PNG files; the JPGs are sent to their PLM system while the PNGs are used in their website (transparent PNGs allow the image to maintain the background of the website). The JPGs are later provided to their ERP, sourcing system and data warehouse. With each image, the metadata is used to create and update records in each system. Since the data is “sync’d” between systems, it is possible to query related data across multiple systems.
Another customer implements this approach to integrate Illustrator files to their Digital Asset Management (DAM) system. The DAM acts as an integration hub feeding data and images to all their other business systems. Any changes made to the images or metadata are fed downstream via the DAM.
By using generic tools configured with industry standards, this approach has provided integration with dozens of DAM, PLM, ERP and other business systems. This approach is not limited to just Adobe Illustrator files as many file types now support custom XMP metadata; even files that don’t support XMP can participate using “sidecar” XML files. Even image files can be related to each other; if the design sketch has the same identifying metadata as a photo, a sample’s photo can be used in a report replacing the previous sketch. The opposite can also happen; a customer service representative can access the design specs for a product by using the metadata contained in the catalog’s photo of the product.
When the data is collected at its origin and passed along with the image, the image becomes the driver for the workflow through the enterprise.