Scenario 66 - Test Specification

66.0 Overview Scenario #66 describes the integration among stakeholders that either manage or use Test Specifications.

The purpose of this scenario is to enable the visualization of the participants in the process and the dialogs between them for this specific integration. This scenario is not meant to be the only model for exchanging Test Specifications. This is simply one model that may be used to guide one’s own integration efforts.

There are a variety of scenarios where Test Specifications will be exchanged to support testing, and different systems or business functions will be involved in these scenarios. Some stakeholders involved in exchange of Test Specifications include:

  • Product Lifecycle Management
  • Purchasing / Procurement
  • Order Management
  • Quality Management
  • ManufacturingOperations
  • Lab Information Management
  • Third Party Lab

This is not a complete list but is meant to be a representative sample of activities that manage or use Test Specifications in quality management processes.

66.1 Scenario Diagram

The scenario below contains the participants involved in the interaction, the dialog flows or conversation between them, certain assumptions about the sequence of events, and assumptions about the technical approach, for example, publish and subscribe.

This is a model to be used as a design recommendation, not a required approach..

66.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach with transaction management required but not explicitly defined.

This scenario describes a model in which the �owner� (aka the system of record) of test specification master data interacts with one or more users that need copies of that data. The environment for this integration may be within a single organization or it may include several external organizations. There may be instances where all of the data is contained in the documents and other instances where additional information accompanies the TestSpecification documents.

This scenario assumes that the product lifecycle management component owns the TestSpecification description and the instances of data within it. TestSpecifications are versioned, and this scenario illustrates pushing revisions to users. However, it does not specify how information about prior versions are managed, maintained, or recovered.

66.3 Participant Definitions

This scenario contains three participants: Product Lifecycle Management (PLM), Quality Management, and Laboratory Management. Typical capabilities of these participants are described:

  • PLM manages the definition of the product, what equipment is required to produce and test the product, the qualification of the equipment, and provisioning of the equipment at a facility that produces or tests the product.
  • Both Lab Management and Third Party Lab participants use an application often referred to a Lab Information Management Systems (LIMS). LIMS will manage testing services, and collect data off test instruments.
  • LIMS system may receive equipment definition information from the PLM system, but the configuration of that equipment is still performed within the LIMS system.
  • Maintenance and calibration schedules may be defined in the LIMS system and have access to maintenance records, potential stored in another application.
  • A Third Party Lab should manage its own equipment, however, may receive TestSpecification(s) from a customer. A Third Party Lab is not included in this scenario, but may replace Lab Management in those specific implementations.
  • The Quality Management participant could receive TestSpecification(s) from the PLM system to validate compliance that specific tests were performed in order to produce a Certificate of Analysis for a lot.

The actual definitions and details of these applications are left to the designer but are assumed to contain the functionality as defined by systems commonly sold in the commercial marketplace today. This definition is broadly accepted by the scenario designers and is a direct result of the decision not to define how the processing takes place within any individual application.

Each application must be able perform the services defined by the message BOD (business object document), but the internals of the application are not required or desired to be exposed at this level of standardized abstraction.

The most important factors in defining these participants is to ensure that an integration designer can communicate the requirements precisely enough to detail the interfaces needed and their interrelationships.

66.4 Business Workflow (Sequence)

The business workflow is graphically represented by starting at the Scenario top and reading from top down and from left to right.

The diagram illustrates the workflow stages involved with the sending and updating a TestSpecification. Test specifications are specifications of the sampling, tests, and result ranges required for a particular item (product or input material) to match the quality requirements of the business or particular customers. A Test Specification is configuration managed master data. A revision will result in a new version with a different RevisionID and effectivity and will likely change the effectivity of a prior version.

Inspection Orders, Test Results, or Certificates of Analyses may include references to Test Specifications. Test Specifications are tracked, and should be preserved / archived for later examination. Audits may trace back to particular Test Specifications in order to determine sampling requirements, tests conducted, and acceptable ranges of results. While no particular strategy is prescribed for managing versions, it is recommended that either references to Test Specifications directly include version information or that effectivity histories for Test Specification versions are kept so that the date of an Inspection Order or testing could be used to infer the version of the Test Specification employed for an inspection.

The sequence diagram illustrates, with arrows, the messages exchanged, and their responses. A ConfirmBOD provides an acknowledgement to the initial request indicating that the request was received and understood as a valid. An Acknowledge(noun) message indicates that the transaction was processed (committed), and a business person has reviewed and provided information related to the next step (accepted, rejected, etc.).

The data exchanges involved within the business process are as follows.

  1. The first business event in the integration scenario is the transfer of a new TestSpecification from Product Lifecycle Management to Quality Management. This uses the ProcessTestSpecification BOD.
  2. In second business event, Quality Management acknowledges its receipt and filing of the new TestSpecification using the AcknowledgeTestSpecification BOD.
  3. The third business event is the transfer of the same TestSpecification from Product Lifecycle Management to Laboratory Management, using the ProcessTestSpecification BOD.
  4. In fourth business event, Laboratory Management acknowledges its receipt and filing of the new TestSpecification.
  5. The fifth business event in the integration scenario is the transfer of a revision to an existing TestSpecification from Product Lifecycle Management to 7. 6.Quality Management, using the SyncTestSpecification BOD.
  6. Quality Management in the sixth business event sends the SyncResponseTestSpecification BOD back to Product Lifecycle Management acknowledging the revision.
  7. The seventh business event in the integration scenario is the transfer of a revision to an existing TestSpecification from Product Lifecycle Management to Laboratory Management.
  8. Laboratory Management in the eighth business event sends the SyncResponseTestSpecification BOD back to Product Lifecycle Management acknowledging the revision.
  9. The final business event acknowledges the revision of the TestSpecification. This uses the SyncTestSpecification BOD, since the PLM or middleware is likely using a pub/sub approach. ChangeTestSpecification BOD may also be used to for direct integrations between applications that are not using pub/sub.

66.5 Exception Handling

Exception handling is highly localized as the result of how business capabilities are implemented including the deployed infrastructure, management and business rules. As such, this section of the Scenario documentation is planned to be used as a guide to help understand the additional intent of these Scenarios. If no exceptions are noted here, then it can be assumed that the Scenario designers agreed that the Scenario is straightforward and has no additional needs:

  • The Confirm BOD is typically intended to be used by the original receiving application to communicate to the sending application that the information it sent in the message BOD (business object document) was received and understood and can be processed.

  • If the information was not received or understood, or contained errors of any type, it is accepted practice for the OAGIS users to presume that the data was not acted on.

  • In the absence of a Confirm BOD within a previously agreed time limit (e.g., SLA, normally defined in an out-of-band agreement), the originator will resend the original message.

  • As errors and assumptions are the bane of any implementation, it is strongly recommended that the Confirm BOD be used to prevent any potential problem although it is not a requirement by OAGIS use.


OAGi and its members welcome your feedback.