Integrating robust systems such as EPDM, Intralink and Agile PLM can be a pretty complex task. This is especially true when you consider that different companies will have different business processes revolving around each system's use. The DesignState platform, from Zero Wait-State, has been around for quite some time now but it is still a mystery for a lot of potential customers because they want to know what it does. Our out of the box solution (what it does) is very basic for PDM to PLM:

• Gather the required information from the exported BOM
• Create or modify Agile parts transferring attribute information
• Attach CAD file or secondary content - this is different than an Intralink export containing the internal CAD references. Exporting the structure for placement within intralink requires additional work whereas EPDM integrations do not
• Create Change Orders automatically or modify an existing change order if the CAD object is already on an ECO. The out of the box solution will use a single change order subclass and workflow. For example, the out of the box policy may create Default Change Orders using the Default Workflow. Criteria can be defined for custom change and workflow selection as a customization option.

Is this what you need? Well maybe, but it probably isn't exactly what you need. Here are the highlights of our solution and how they help facilitate integration:

• Plug-ins: First of all you may be working with systems other than EPDM, Intralink/PDMLink, and/or Agile. To accommodate this, we have an architecture that relies on plug-ins to talk to different repository types. Each plug-in implements a well defined set of interfaces which makes it relatively easy to add new connections. These plug-ins are used by the publishing engine to get or set information in the endpoint.
• Event Handlers: Event handlers are required for us to receive notice that something has taken place in the source or target repositories. DesignState can receive notifications via a number or different ways including pure socket calls, http, web services or even custom polling or file watching. As you will see in the video, configuration of event handlers is very straight forward.
• Publishing Engine: Once events are received and we have the capability to interact with an endpoint, we need to know how to process the information. We attempt to handle this in a repository independent manner wherever as possible through custom policies. A policy is an XML document that has sections defining what information to retrieve from the source system, any transformations that need to take place, custom use cases for publishing, and finally the cancellation or commitment of the changes requested in the target system. DesignState can accommodate multiple policies and can match a policy to an inbound event based on the data seen in the event.
• Supporting Services: Synchronization is the key to DesignState as it tracks what it has published before an maintains state between source and target systems. In addition other services such as notifications and internal process recording are also provided.

While this does not provide an in depth understanding of all technical aspects of the product, I hope that it provides a general understanding as to the customization possibilities that the architecture provides.

This video will show some of the core files used by DesignState, including the event handler configuration, repository settings and the sections of a policy used by our rules engine.