Upload
talalquider
View
18
Download
1
Embed Size (px)
DESCRIPTION
Papazoglou Webserv 2e Cs Solution Notes Part2
Citation preview
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
Part 2 – Business Process Modeling & Business Service Analysis
1 – Introduction This report aims at the study and application of a top‐down Service Oriented
Architecture (SOA) development approach to the AVERS Supply Chain, which was described in detail in the literature review of the previous assignment.
The remainder of this report is structured as follows: The first section describes the core business processes involved in each domain of the Supply Chain – i.e. Supply, Manufacturing and Distribution. The following section describes the interactions between the domains using the BPMN 2.0 Modeling approach.
The next section aims at explaining the identification of the business services that perform the activities, and provides an abstract design of each service – the functionality along with the respective input and output object. Finally, it describes the consolidation of the services and how SOA principles are applied in order to use all the functionalities in a loosely coupled manner in the AVERS Supply Chain.
2 – AVERS Supply Chain: Core Processes As mentioned in the previous assignment, the ANSI/ISA‐95 is a standard that provides models and terminology for defining the interfaces between an enterprise’s business system and its manufacturing control systems. In this assignment, ANSI/ISA‐95’sfunctional flow data model presented in Figure 1will be used to define the core processes involved in each domain of the Supply Chain.
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
Figure 1 – The Main Manufacturing Functions and Information Flows
ANSI/ISA‐95 standard defines 12 core functions regarding manufacturing enterprises and further defines for each of those their inherent sub functions. In the previous assignment only 3 of the functions were defined as vital, since the scope of the document was to deal strictly with the order processing and manufacturing domain of AVERS. However, since in this assignment there was a change in scope, it will be needed to include 4 other functions to cover all 3 domains of the supply chain.
It was decided to leave out of the scope of this project the following functions: Quality Assurance; Product Cost Accounting; Maintenance Management; Marketing and Sales; and Research Development and Engineering. It is believed that these are support functions for the core domains of the supply chain, and for the sake of simplicity should not be detailed.
The functions which are identified as our core processes are as follows, with its sub processes as defined in the Standard:
• Order Processing o Customer order handling, acceptance and confirmation; o Sales forecasting; o Waiver and reservation handling; o Gross margin reporting;
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
o Determining production orders.
• Production Scheduling o Determine production schedule; o Identify long‐term raw material requirements; o Determine pack‐out schedule for end products; o Determine available product for sales.
• Production Control o Controlling the transformation of raw materials into end product in accordance
with production schedule and production standards; o Performing plant engineering activities and updating of process plans; o Issuing requirements for raw materials; o Producing reports of performance and costs; o Evaluating constraints to capacity and quality; o Self‐test and diagnostics of production and control equipment; o Creating production standards and instructions for SOPs (standard operating
procedures), recipes, and equipment handling for specific processing equipment.
• Material and Energy Control o Managing inventory, transfers, and quality of material and energy; o Generating requests for purchasing of materials and energy based on short‐
and long‐term requirements; o Calculating and reporting inventory balance and losses of raw material and
energy utilization; o Receiving incoming material and energy supplies and requesting quality
assurance tests; o Notifying purchasing of accepted material and energy supplies.
• Procurement o Placing orders with suppliers for raw materials, supplies, spare parts, tools,
equipment and other required materials; o Monitoring progress of purchases and reporting to requisitioners; o Releasing incoming invoices for payment after arrival and approval of goods; o Collecting and processing of unit requests for raw materials, spare parts, etc.,
for order placement to vendors.
• Product Inventory Control o Managing inventory of finished products; o Making reservations for specific product in accordance with product selling
directives; o Generating the pack‐out end product in accordance with delivery schedule; o Reporting on inventory to production scheduling; o Reporting on balance and losses to product cost accounting; o Arranging physical loading/shipment of goods in coordination with product
shipping administration.
• Product Shipping Administration
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
o Organizing transport for product shipment in accordance with accepted orders
requirements; o Negotiating and placing orders with transport companies; o Accepting freight items on site and releasing material for shipment; o Preparing accompanying documents for shipment (BOL, customs clearance); o Confirming shipment and releasing for invoicing to general accounting; o Reporting on shipping costs to product cost accounting.
Even though it is believed that these processes are all important to the whole AVERS supply chain, they are still too complex due to exaggerated detail on some support processes, such as accounting and energy management. Therefore, for the sake of simplicity, a thorough revision in all sub processes was made, in order to leave only those entirely relevant to the core supply chain comprising all 3 domains.
Notwithstanding, it was decided to group some of the top‐level processes that are closely related to simplify the modeling, such as the grouping of Order Processing and Production Scheduling in a single core process.
The modified core processes and its inherent sub processes are defined as follows:
1) Order Processing and Production Scheduling a. Customer order handling, acceptance and confirmation; b. Waiver and reservation handling; c. Determining production orders, schedule and available product for sales.
2) Production Control a. Check accordance of schedule with production schedule and standards; b. Performing plant engineering activities and update of process plan; c. Issuing requirements for raw materials; d. Transformation of raw materials into end products.
3) Material Control and Procurement a. Managing inventory; b. Managing transfers of material; c. Placing orders with suppliers for raw materials, supplies, spare parts, tools,
equipment and other required materials; d. Monitoring progress of purchases and reporting to requisitioners; e. Receiving incoming material supplies; f. Releasing incoming invoices for payment after arrival and approval of goods.
4) Product inventory control and Product Shipment Administration a. Managing inventory of finished
products; b. Making reservations for specific product in accordance with product selling
directives; c. Organizing transport for product shipment in accordance with accepted orders
requirements; d. Negotiating and placing orders with transport companies;
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
e. Releasing material for shipment; f. Preparing accompanying documents for shipment; g. Confirming shipment and perform invoicing.
These processes and sub processes will be further detailed in the next session of this document in BPMN models.
3 – BPMN Modeling This section describes the modeling of the four core processes and their sub‐process
using the BPMN 2.0 notation. The tool used to model the processes was Signavio.
Order Processing and Production Scheduling:
The file Order_Processing_Production_Scheduling.pdf shows the modeling of this core process. The three sub‐processes shown here are displayed in the subsequent pages, with relevant meaningful naming.The ‘Making reservations for specific product in accordance with product selling directives’ and ‘Raw Material Supply AVERS’ sub‐processes are covered in the ‘Material Control & Procurement’ core process.
Production Control:
The file Production_Control.pdf shows the modeling of the entire production control process. When a Production Request is received, the system first assures that it has means to fulfill the order, by checking if the production process is well known (existence of product rule) and if it can have enough raw materials. If none of these conditions are met, the order is then rescheduled so that these constraints can be further met. If the conditions are met, the system verifies if the needed raw materials are already available and allocates it to the production line. If not it requests its movement to the production line before allocation. When the raw material is finallyreserved for production, the system commands the beginning of the order with the allocated resources and,when finished,transfers the products from its temporary storage to the destination warehouse.
Material Control and Procurement:
The file Material_Control_and_Procurement.pdfshows the sub‐processes and their respective activities that are performed by the raw material supply department of AVERS OEM, as well as the interactions with the external material suppliers. There are basically three important entities that the raw material supply processes deal with: the material request orders, the replenishment orders and the material transfer orders. The first correspond the internal requests within AVERS from different departments to the raw material supply department. The second are the purchase orders sent to external material suppliers. Finally, the third are the orders to move stock from warehouses to the locations which requested them.
Product inventory control and Product Shipment Administration:
The file Product_inventory_control_and_Product_Shipment_Administration.pdf shows the process model covering shipment details like selecting a logistics carrier, organizing the
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
shipment, etc. Furthermore, inventory activities are modeled like updating the inventory after sending a product to a customer, sending an invoice to the customer, etc.
4 – Business Service Analysis In this section, the various business services that perform all the process activities in the previous sections are defined. A business service basically consists of an abstract design specifying the Main Functionality, the input parameters and the output of the functionality. It is designed such that it can be implemented by any IT service. The following illustrates the Business Services defined in each of the core processes of the AVERS Supply Chain.
Order Processing and Production Scheduling:
Order Management Services:
Register Purchase Order Customer Name Customer Address Customer SSN / Tax Number Customer Credit Card Number ( IF individual) Ordered Item
INPUT Purchase Order
Quantity Order ID (Primary Key) Customer Information Ordered Item
OUTPUT Purchase Order (Registered)
Quantity Verify Purchase Order
Order ID (Primary Key) Customer Information Ordered Item
INPUT Purchase Order (Registered)
Quantity Order ID (Primary Key) OUTPUT Verification Result Boolean (Accepted/Rejected)
Consolidate Single Order Customer Status (standard/preferred/individual) Order ID (Primary Key) Customer Information Ordered Item
INPUT Purchase Order (Verified)
Quantity Order ID (Primary Key) Customer Information Ordered Item(s)
OUTPUT Purchase Order (Consolidated)
Quantity Create BILL
Order ID (Primary Key) Customer Information Ordered Item(s)
INPUT Purchase Order (Consolidated)
Quantity OUTPUT BILL Order ID (Primary Key)
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
Customer Information Ordered Item(s) Quantity Product(s) Price (excluding Shipping Cost)
Customer Relationship Management Services:
Check Customer Type Order ID (Primary Key) Customer Information Ordered Item
INPUT Purchase Order (Registered)
Quantity OUTPUT Customer Type Standard/Preferred Retailer / Individual Check Credit Worthiness (Individual Customers)
Customer SSN / Tax Number INPUT Customer Information Customer Credit Card Number
OUTPUT Credit Worthiness Status Boolean (Success / Failure)
Production Control:
Production Request Services
Create Production Request Product Type ID Product Rule ID Production Line ID Quantity
INPUT Production Request Information
Storage Warehouse OUTPUT Production Request
Order Information Production Request Order ID
Create Product Rule Not Found Alarm Product Rule ID INPUT Product Request
Information Product Type ID OUTPUT Alarm Information Alarm ID CreateNot Enough Raw Material Alarm
Material ID INPUT Material Information Quantity
OUTPUT Alarm Information Alarm ID Reschedule Production Request
Production Request Order ID INPUT Production Request Order Information Error Type
Production Rule Services
Check Existence of Product Rule INPUT Production Rule Product Type ID
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
Information Product Rule ID
OUTPUT Production Rule Information Response
Is Production Rule Available (Boolean)
Check For Substitute Product Rule Product Rule ID INPUT Production Rule
Information Product Type ID OUTPUT Substitute Production
Rule Information Substitute Product Rule ID
Production Line Services
Check Compliance of Production Line to Product Rule Product Rule ID Production Request Order ID
INPUT Production Schedule Information
Production Line ID OUTPUT Production Line
Information Response Is Production Line Ready for Product Rule (Boolean)
Prepare Production Line Product Rule ID Production Request Order ID
INPUT Production Schedule Information
Production Line ID Production Line ID Production Line Resetting ID
OUTPUT
Production Line Information Response
Is Production Line Ready (Boolean) Allocate Raw Material To Production Line
Product Rule ID Production Request Order ID Production Line ID
INPUT Production Schedule Information
Quantity Material ID Quantity Allocated Location ID Product Line ID
OUTPUT
Material Allocation Data[]
Production Request Order ID Produce End Product According To Product Rule
Product Rule ID Production Request Order ID Production Line ID
INPUT Production Schedule Information
Quantity Production Response ID Production Lot ID Product ID
OUTPUT
Production Data[]
Temporary Storage Location ID Move Product to Inventory
Production Response ID INPUT Production Data Storage Warehouse
OUTPUT Product Movement Product ID
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
Origin Location ID Destination Location ID
Data[]
Production Response ID
Raw Material Services
Check Availability of Raw Materials Material ID INPUT Production Rule
Information Quantity OUTPUT Production Rule
Information Response Is Raw Material Available (Boolean)
Request Transfer of Raw Material to Production Line Material ID INPUT Material Movement
Request Data[] Quantity Material ID Quantity Moved Origin Location ID
OUTPUT
Material Movement Data[]
Destination Location ID
Material Control and Procurement:
Inventory Management Services
CheckInventoryStatus Material ID INPUT Material Information Needed Quantity Amount Avaialbility (Boolean) Material Data (ID, name, characteristics, etc)
OUTPUT Inventory Information
Stock Data (number, location) CreateTransferMaterialOrder
Material ID Source Location Destination Location Requested Quantity
INPUT Material Transfer Information
Requisitioner Data Transfer Order ID Material Data Quantity Source Location Destination Location
OUTPUT Material Transfer Order Information
Estimated Delivery Date and Time StockReceivedMaterial
Replenishment Order ID Material Data Storage Location
INPUT Material Information
Quantity OUTPUT Stock Operation Material Data
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
Quantity Stored Storage Location
Information
Operation Success Flag (Boolean)
Material Request Services
CreateMaterialRequest Material ID Requisitioner Data Quantity
INPUT Material Request Information
Delivery Location Request Order ID Requisitioner Data Material Data Quantity
OUTPUT Material Request Order Information
Delivery Location CollectMaterialRequestsTo Replenishment Order
Material ID INPUT Material Request Information Requested Quantity
Replenishment Order ID OUTPUT Grouping Replenishment Order Information Is Ready to Dispatch (Boolean)
UpdateMaterialsDeliverySchedule Replenishment Order ID Material Data Quantity Delivery Location
INPUT Material Delivery Schedule Change Information
Estimated Delivery Date and Time Replenishment Order ID Material Data Quantity Delivery Location
OUTPUT Material Delivery Schedule Information
Estimated Delivery Date and Time CheckOrderCompliance
Replenishment Order ID Received Material Data
INPUT Replenishment Order and Received Material Information Received Quantity
Replenishment Order ID Material Compliance Flag (Boolean)
OUTPUT Order Compliance Information
Material Quantity Compliance Flag (Boolean) CheckMaterialSpecificationCompliance
Replenishment Order ID INPUT Replenishment Order and Received Material Information
Received Material Data
Replenishment Order ID OUTPUT Order Compliance Information Material Specifications Compliance Flag
(Boolean)
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
Supplier Relationship Services
FindSupplier Material Data Requisitioner Data Requested Delivery Location
INPUT Requested Material and Location Information
Requested Quantity Supplier ID OUTPUT Supplier Information Supplier Data (name, address, etc.)
ReleaseReplenishmentOrderInvoice Replenishment Order ID Expected Payment Date
INPUT Replenishment Order Data
Payment Method Replenishment Order Data OUTPUT Replenishment Order
Invoice Invoice Data
Notification Services
NotifyRequisitionersMaterialRequestStatus INPUT Material Request
Information Request Order ID
Request Order ID Requisitioner Data Request Order Status
OUTPUT Notification Information
Notification Date NotifyRequisitionersDeliverySchedule INPUT Request Order
Information Request Order ID
Request Order ID Delivery Location Estimated Delivery Date and Time Quantity
OUTPUT Notification Information
Notification Date NotifyRequisitionersAvailableMaterial INPUT Replenishment Order
Information Request Order ID
Request Order ID Material Data Stock Location Available Quantity
OUTPUT Notification Information
Notification Date
External Supplier Services
QuoteMaterialPrice Material Data INPUT Material Information Requested Quantity
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
Requested Delivery Date Material Data Price
OUTPUT Quote Information
Payment Data PlaceMaterialReplenishmentOrder
Material Data Quantity Requested Delivery Date Delivery Location
INPUT Requested Material Information
Agreed Price Replenishment Order ID Material Data Estimated Delivery Date and Time Delivery Location Final Price
OUTPUT Replenishment Order Information
Payment Data CheckMaterialReplenishmentOrderStatus INPUT Replenishment Order
Information Replenishment Order ID
Replenishment Order ID Current Status Estimated Delivery Date and Time
OUTPUT Replenishment Order Status Information
Delivery Location CheckPaymentConfirmation
Replenishment Order ID INPUT Replenishment Order Information Payment Data (date, amount, mean, etc.)
Replenishment Order ID OUTPUT Payment Confirmation Information Payment Confirmation Flag (Boolean)
Product inventory control and Product Shipment Administration:
Prepare Inventory Results for Logistics Provider Order ID (Primary Key) Customer Information Ordered Item(s) Quantity
INPUT BILL
Product(s) Price (excluding Shipping Cost) Ordered Item(s) Number of Items Warehouse Address (Shipment Pickup)
OUTPUT Shipment Information
Delivery Address Collect Shipment Quotes
OrderID Ordered Item(s) Number of Items Warehouse Address (Shipment Pickup)
INPUT Shipment Information
Delivery Address
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
OrderID Carrier Expected Shipment Date Expected Delivery Date Shipment option
OUTPUT Shipment Details
Total shipment price Book selected route/carrier
Carrier Number of Items Expected Shipment Date Expected Delivery Date
INPUT Shipment Details
Total Shipment Price Order ID (Primary Key) OUTPUT Approval Status Boolean (Approved/Rejected)
Inform pick‐up date for products(Notification) INPUT Shipment order details Order ID
Shipment Order ID Shipment Pickup Date Warehouse Address (Shipment Pickup)
Delivery Address Inform updated Shipment Status (Notification)
Order ID Shipment Order ID Carrier Number of Items Expected Shipment Date Expected Delivery Date Shipment Selected Warehouse Address (Shipment Pickup) Delivery Address
INPUT Shipment order details
Total Shipment Price Send Invoice (Notification)
Order ID (Primary Key) Carrier Number of Items Delivery Address Shipment Date Customer Information Total Shipment Price Ordered Item(s) Quantity
INPUT Shipping Order Confirmation
Total Price (including Shipping Cost)
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
5 – Application of SOA Design Principles The design of a SOA system is based on a clear definition and description of underlying services, which can then be composed in required ways to execute complete business processes. The Business Services, as we may call them, provide a technical grounding to execute a function, or provide an interface to access a system. The design of these services must be done in such a way that each piece of functionality is modularized properly into a Business Service that can be invoked independently, with the appropriate input parameters. Finer operations that must be executed in a special sequence, or ones that require state to be maintained, must be encapsulated into business functions that can be invoked on their own. The following is a description of a few design decisions that have been made based on the SOA design principles as outlined in the problem description:
High Cohesion: The business services that have been described must be flexible enough to be able to be executed in any order. The arguments it accepts as input must contain all the information required to perform that business service, so that any chaining of information interchanges between services is not necessary. In the Order Management Business Services description, it can be seen that all the business functions accept the Order Id as the main key for performing operations. To get any details about orders, or customers related to that order, the Order Id can be supplied to get the initial information, which can then be used to perform additional operations. Any new application or service bus that needs to interface with these services just needs to know the interface definition and make the corresponding calls. This allows us to have an architecture with a high degree of cohesion. If this is absent, we might have different applications with unstandardized interface definitions, different message formats etc. which reduce interoperability. In such a case, more intermediaries like adapters and message transforming components will have to be added. In some cases, the interface return type definitions can be missing key information that is not retrievable by other ways. We have attempted to keep these issues in mind while designing the business services.
Loose Coupling: This is closely related to the principle of High Cohesion. It deals with standardized and self‐contained input and output parameters, which means that any application which has this information can invoke the business service. This means that there is no implied information or shared database which supplies working data that is not passed through the business service interface. At the physical implementation level, it will also mean that there is a common infrastructure for invoking a business function, which allows any service to be invoked seamlessly of its physical implementation details (e.g. CORBA, Web Services). Loose coupling also includes asynchrony in operation. For example, the Ordering process is divided into functions like Customer checks, Quantity retrieval, payment processing etc. Each business service operates on its own, and can execute in parallel with the others. On the level of a single process, all operations that can be done in parallel, such as
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
customer checks and quantity retrieval, can be done in parallel. Execution can move on without waiting for the results of any business function. On a process engine level, components that that have a higher priority and/or larger volume, can be made redundant to be able to service requests from many process instances simultaneously.
Appropriate Granularity: Determining the level of granularity for a business function is of prime importance. Choosing a level of granularity that is too fine will result in a very large service portfolio. This will typically include many services that are executed in the same orchestration, and hence which belong to the same logical service. It will result in a cluttered SOA design which might complicate the design of the end business processes. If the level of granularity is too coarse, it might result in a design that makes it impossible to invoke specific business functions. For e.g., in the order process, if approve shipping details is included in the bill generation function, they will be tied together, and it will be impossible to approve shipping details at a later time, in an asynchronous manner. It is important to note that the business services defined will be further developed from infrastructural and component based services, so it will always be possible to drill down the business services to finer components. It is not these lower level views of the SOA design that are described here. The granularity of the business functions should also be at an appropriate level so that the business processes that execute them can do it in a dynamic and lucid manner.
Service Oriented Architecture Case Study
Part 2 – Business Process Modeling & Business Service Analysis
6 – Conclusion The Business Process Modeling of the AVERS supply chain described in this document
shows the importance of the top‐down SOA development approach. The ANSI/ISA‐95 standard is used to define the core processes, along with the respective sub‐processes in each domain of the Supply Chain. Then, the BPMN 2.0 is used to model the identified processes and sub‐processes using the Signavio Tool. In the next step, the business services that perform the process activities are designed in an abstract manner, specifying the Main Functionality, the input parameters and the output of the functionality. The purpose of such an abstract design is for the ease of implementation by any IT Service. Finally, it is seen how the design of the business services is consolidated by applying the different SOA design principles.