Generic Tools–The Key to Simple Integration

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.

This article originally appeared in WhichPLM: http://www.whichplm.com/editors-choice/generic-tools-the-key-to-simple-integration.html

Advertisements

E-Spec’s Tag-It! -an informational webinar

E-Spec’s Tag-It! makes it easy to apply custom and standard XMP metadata to your assets and files.

In a nutshell:

Tag-It!:

• Collects metadata and embeds it in the Adobe Illustrator (.ai) file and all Convert-It! generated alternative files

When importing an image into a Product Lifecycle Management (PLM) system, the Designer is typically required to also enter relevant data into the PLM system. This means opening PLM, manually importing the image and then entering data into PLM before saving the image. By embedding the metadata in the image, the PLM system can automatically import the image along with the metadata and place both the image and the data into the PLM database. If the image or the metadata is modified the PLM system can automatically update the database.

Tag-It! allows the Designer to stay in the Illustrator application, simply entering the metadata and saving the file. The Designer does not need to switch to the PLM system, saving time and eliminating mistakes.

• Implements business rules while entering the metadata

Tag-It! is configured to match the metadata to the customer defined fields and standard fields in the PLM system. Features like required fields, validation lists, dependent validation lists, default values and hidden fields allow Tag-It! to provide valid data to the PLM system with minimum user interaction.

Tag-It! makes it easy for the Designer to provide the required data. Default values mean that repetitive data does not have to be entered. For example: If I usually work in “mens”, the division field can be defaulted to “mens”; if I am working on an exception, a  “kids” style; I simply select “kids from the list. If I always work in “mens”, the division field can be defaulted to “mens” and also hidden so I don’t even see the field in Tag-It!’s dialog but the value “mens” is still embedded in the file. Dependent fields allow Tag-It! to provide only valid data to the PLM system. If the product type field is dependent on the division field then when I select “mens” the validation list for product type displays “pants”, “shorts”, “jeans”; when I select “womens” in the division field the validation list for product type changes to “dresses”, “skirts”, “pants”, etc. This means that valid data is provided to the PLM system.

Creating Digital Asset Workflows using Metadata –How to make your files Self-Aware

Creating Digital Workflows using Metadata or How to make your files Self-Aware

My company, E-Spec has been using Adobe XMP metadata for over 8 years now. I began following Digital Asset Management (DAM) groups when I joined LinkedIn a few years ago. I continue to be amazed at how perception of the same technology can vary based on your background. The DAM view seems to be that metadata is primarily a tool for retrieval of assets (in most cases images) with a historical tilt towards an archive solution. E-Spec views metadata as a means for system integration and reducing redundant data entry in the business process. I would like to solicit some discussion — how can these different views can work together to create more robust DAM and integration solutions.

Keywords vs. Attributes

Our mantra for process improvement is “collect the data at the source and eliminate redundant data entry between systems”. The data of interest is “attribute” data whether it is product attributes, image attributes or file attributes. As the user “publishes” their content for collaboration, they know certain attributes. The goal is to capture these attributes just as the users share their files. Most corporate creative departments allow each user a personal workspace (still on the network so IT maintains the backups) and provide “share” locations where users can collaborate together on this content. In the shared locations, we find “attributes” are maintained using folder/sub-folder structures and specific “coding” in the actual file names (did you bring your Dick Tracy decoder ring?). The types of attributes might be the consumer/customer of the content, the type of content or other product information; for example in the fashion world: season, collection, product type, gender, size range, etc.

What I have observed from the DAM discussions is more of a content emphasis; the keywords represent the visual content in the file; the image is of a “dog”, a “retriever”, a “golden retriever” and it is in a “fenced yard”, in the “mountains”, etc. Back to the fashion example, the keywords might include; “dress”, “knee-high”, “floral pattern”, “sleeveless” – things that anyone looking at the file can see. Note that some of these keywords might also be considered attributes, but many attributes could not be derived by observing the contents of the file. From looking at the dress, I cannot tell that it belongs to a particular season (Fall 2015) or is intended for a particular customer (Macy’s) or a marketing collection (Martha Stewart). So while attributes and keywords are related and even overlap, their methods of collection may be different.

Attached vs. Embedded

Another distinction I have observed in the different approaches is how the data is captured. The DAM system catalogs the files and keywords are entered in a database with links to the file (asset). Some of the data may or may not be embedded in the file but a large portion of the data is only contained in the database (a general observation – varies by system/vendor). If the asset is checked out the linked data may or may not travel with the asset. Our approach has been to immediately embed attribute data in the file; if the file is moved or copied the attributes still exist in the file (the asset has become “self-aware”). If I make a copy of the file and send it to another department for use in their business system, the attribute data is available to integrate the file with other existing business data. If I place the file in a shared “drop box”, the recipient still has access to the attributes in his copy of the file. And if I provide the file to a DAM system, the attributes can be extracted and included with the keywords already being entered. Embedding attributes in the file means the file knows to whom and where it belongs, it knows which external data elements are relevant to it and it can be a conduit for system/data integration.

Self-aware Documents

The optimum approach is to create the attribute taxonomy and vocabulary to match the business applications used in the enterprise workflow. A sub-set of the attributes can be used to identify a key to a single record in a particular database; different sub-sets for different systems. The creative user is creating an image to be used in producing the previous discussed dress. As they save their work to the shared location, they know some of the attributes; season, customer, collection, gender, product type. As other users work with them, other attributes become known; size range, color, target price, etc. At some point an ID is assigned (prototype #, style #, etc.). Sending a copy of this file to a product development database, a unique record can be created for this style using the embedded attributes. The product development system will then collect additional data about our dress as it progresses through the product workflow (sampling, sourcing, production). This data might be related to the fit of the dress, the required components to make the dress and even the cost. If another copy of the file is sent to an inventory/production system, a unique record can be created there as well. Additional data will be collected regarding factories, ship dates, quantities, etc. Other copies of the file might be sent to e-commerce websites, sourcing systems, etc. The file is provided to our DAM system as well. A user can use the DAM system to find the dress and knowing the attributes, can query the other business systems to get information such as status, sales results or any other data in those databases related to our dress. The dress image has become self-aware!

This does not replace or interfere with the traditional DAM approach; it simply provides some data (attributes) earlier in the cycle. Keywords can still be added to our dress (“floral print”, “roses”, etc.) at any point.

The integration doesn’t stop with business systems. At some point a photo is taken of our dress to be used in a catalog. If we embed the same attributes in the photo, then later when customer service gets a call about the pink floral dress in the catalog, the metadata can be used to look up in the inventory system how many size 6’s are in stock; they can look up in the product system if the dress fits the same as last season’s model, etc. The photo can take me to the original sketch and from there to the rest of the enterprise.

The point is the taxonomy and vocabulary requirements are different when using metadata for integration and need to be included in your DAM implementation planning – it can’t be added after the fact.

In creative and graphic-intensive enterprises, the DAM system can become the hub of data integration by using “self-aware” images.

About E-Spec, Inc.

E-Spec, Inc. (founded in 2001) offers a suite of Adobe extensions and other tools to establish a digital media workflow within the creative process. Free yourself from the mundane work of identifying, converting, publishing and tracking of media files and focus on what you do best, create!

Dan Hudson, President E-Spec, Inc. dan@e-spec.net