Scenario 82 - Manage Service Request

82.0 Overview

Scenario #82 describes the integration of business software supporting the process through which Supplier and suppliers can communicate life cycle cost analysis information with manufacturers and sustainability systems. These systems include Engineering - Design PDM Systems, engineering and design systems, financial systems, etc. This reporting analysis information is valuable for decisions regarding sustainability and logistical data.

The purpose of this scenario is to describe the participants in a mainstream business process, and to illustrate how the business systems of those participants can be integrated through messages exchanged to realize the goals of that business process. This scenario is not meant to be the only model for integrating an ERP to a logistics or sustainability management system. It is simply one model that may be used to guide one’s own integration efforts.

Since the function and composition of business software components that might be used to produce or exchange the information described in the scenario vary widely, specific software components will not be described. Software components which might be involved in realizing this scenario include:

  • Customer Party
  • In-Field Service System
  • Engineering - Design PDM System

This is not a complete list but is meant to be a representative sample of systems that might be involved in generation or exchange of the information involved with these logistics and sustainability resources.

82.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.

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

82.2 Assumptions

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

This scenario describes how Supplier systems relay logistics and sustainability information with Technical Publication Management Systems.

By convention, these activities are depicted as messages that start and end at the same business process participant, and do not indicate that actual messages between systems need to be implemented for the processes to take place.

The diagram and descriptions of the business process for this scenario focus on how a successful execution of the business process would take place.

82.3 Participant Definitions

The definitions and details of the applications supporting these participants are left to the designer but are assumed to contain the functionality as defined by what is 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 specify and design the integration processes needed and their interrelationships.

Note that the evolution of eCommerce has yielded independent trading exchanges and other intermediaries between business operations and inventory management providers. Requirements and operations for intermediaries should be similar to direct links between the two components.

82.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 arrows in a sequence diagrams shows the message exchanged, and the response to the message. A ConfirmBOD provides an acknowledge to the initial request that the original request was received and understood as a valid. The 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 sequence diagram illustrates the data exchanges involved within the business process.

  • This integration scenario begins with the Customer Party sending a ProcessServiceRequest to the In-Field Service System. The In-Field Service System in turn creates an internal AcknowledgeServiceRequest from this notification. The In-Field Service System relays this information over to the Engineering Design PDM System.
  • The Design System acknowledges this change to the bill of materials.
  • The Engineering Design System updates the In-Field System with a AcknowledgeBOM message confirming required updates.

82.5 Exception Handling

Exception handling is highly localized as the result of an implementation’s 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 straight forward 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.

Feedback

OAGi and its members welcome your feedback.