bpm-mdm demo script - archive...4 ©sap deutschland ag & co.kg 2011 1. demo script overview 1.1....

Demo Script SCENARIO: BPM4MDM (based on NetWeaver 7.3 and MDM 7.1 SP06) MDM, BPM February 2012 English SAP AG Dietmar-Hopp-Allee 16 69190 Walldorf Germany

2

© COPYRIGHT 2011 SAP AG. ALL RIGHTS RESERVED.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express

permission of SAP AG. The information contained herein may be changed without prior notice. Some software products

marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10,

System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400,

S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER,

OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF,

Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are

trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S.

and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe

Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered

trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium,

Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and

implemented by Netscape.

SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP

products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP

AG in Germany and in several other countries all over the world. All other product and service names mentioned are the

trademarks of their respective companies. Data contained in this document serves informational purposes only. National

product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated

companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group

shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and

services are those that are set forth in the express warranty statements accompanying such products andservices, if any.

Nothing herein should be construed as constituting an additional warranty.

3 ©SAP Deutschland AG & Co.KG 2011

Table of Contents

1. DEMO SCRIPT OVERVIEW .................................................................................................................. 4 1.1. Demo Description 4 1.1.1. Objectives ................................................................................................................................................................ 4 1.1.2. System Architecture ................................................................................................................................................ 4 1.1.3. Process Description ................................................................................................................................................ 6 1.2. Intended audience 7 1.3. Protagonists 8 1.4. Key Messages and Value Proposition 8 1.5. Storyflow Summary 8

2. TECHNICAL REQUIREMENTS ............................................................................................................ 9 2.1. Prerequisites 9 2.1.1. Setting up the Mail Server ....................................................................................................................................... 9 2.1.2. Setting up Mail Addresses ...................................................................................................................................... 9 2.2. System Access Information 10 2.2.1. System Landscape ................................................................................................................................................ 10 2.2.2. Users ..................................................................................................................................................................... 10 2.2.3. Languages Supported ........................................................................................................................................... 11

3. DEMO SCRIPT .................................................................................................................................... 12 3.1. Story FloW 12 3.2. Preparations 12 3.3. Step-By Step Guide 16 3.3.1. Scene 1: Request a New Product ......................................................................................................................... 16 3.3.2. Scene 2: Cancel a Request for Changing a Product ............................................................................................ 35 3.3.3. Scene 3: Create a New Product as Copy ............................................................................................................. 43


1. DEMO SCRIPT OVERVIEW

1.1. Demo Description

1.1.1. Objectives

The demo shows how a typical data maintenance process for SAP Master Data management (MDM) can be implemented using SAP Business Process Management (BPM) and SAP Business Rules management (BRM). The Demo repository is designed for the maintenance of product and partner data. The implemented process involves the product data maintenance. The demo scripts show how the business requirements can be met and how they are implemented technically. The process includes the following features:

Dynamic approver determination for different product categories

Approval step and the option to rework product data or cancel the whole process

Syndication with a potential backend system

Importing of key for external key mapping with a backend product number

Mail notifications The following technical features can be shown:

Usage of the MDM tools o To generate UIs for different maintenance tasks and o To generate Web Services for automated activities.

Monitoring of BPM processes, how to handle errors

Managing business rules with the rules manager in order to change the approver determination on the fly

1.1.2. System Architecture

The picture below shows which systems are involved in the scenario. The BPM process runs on the Composition Environment 7.3 (NetWeaver 7.3). Master data are stored in a MDM 7.1 System. The Master Data Management is the leading system. All changes have to be transferred to the backend system. This should be implemented means of Process Integration (PI). In the current version of the demo this part is still missing.


The next picture shows the system architecture in more detail. The user interfaces used in the BPM user activities are implemented with Web Dynpro and they are utilizing the MDM Web Dynpro components. By working with MDM Web Dynpro components a lot of development effort can be saved because UIs can be easily configured for MDM repository tables. The BPM automated activities are utilizing the generated MDM web service. MDM Web Dynpro components and the generated MDM web services are working on the basis of the MDM Java API which accesses the MDM servers. Furthermore the Busines Rules Management (BRM) is used in the process for approver determination. The transfer to the ERP system will be done by the PI with a suitable adapter (IDOC/web service adapter)

PI7.3

MDM7.1

CE7.3

ECC6.0x

MDM WebService MDM Java API

MDM Syndication

IDoc or ES

Intermediate Message Event (WebService)


1.1.3. Process Description

The requestor starts in the Portal with the Product Maintenance Dashboard. There he can search for existing products and see their data in MDM. From the dashboard he can choose what he wants to do: creating a new product from scratch, creating a new product based on an existing one or changing an existing product. During maintenance of new or existing products they will be checked out. (An existing product is checked out, a new product is checked out as new.) In case of cancellation the product can easily rolled back. After entering the data in the appropriate form the maintenance process is started.


The first step is the approver determination. Dependent on the category different approver groups are determined. The approver groups are maintained in the identity management of the SAP NetWeaver. The Categories are maintained in MDM Table Categories. Each approver belonging to the group determined by the approver determination rule gets an email notification that there is a task for him in the UWL of the portal. Opening the task the approver claims it and the status changes to “In Progress”. The task disappears from the UWL of the other approvers. The approver can decide whether to approve or to reject the request. In case of rejection it is sent back to the requestor for rework. The requestor can cancel the whole process or make the required changes and send the request again for approval. This means that the approver determination (the category might have changed) is called again before the tasks is forwarded to the approval step. In case of approval the syndication is called in order to transfer the new product or the changes to the backend system. Calling the syndication means that an asynchronous web service is called that triggers the syndication. That means there is no synchronous response from the backend that the product was created/changed. In order to be able to proceed only when the backend activities were completed successfully the process listens on a so called intermediate event which is fired from the backend when the product was created/changed. The event provides the external backend product number. In case of a new product the product has to be enhanced with the key mapping for the external product number of the backend system (which can be used later for key mapping purposes). Finally the product is checked in and the requestor receives an email regarding the successful completion of his request.

1.2. Intended audience

Demo is applicable for master data specialists/administrators/stewards as well as for developers.


1.3. Protagonists

The protagonists of the scenario are

Requestors that are requesting the creation of a new product or the change of an existing one.

Approvers that belong to different groups according to different product categories.

1.4. Key Messages and Value Proposition

MDM together with BPM/BRM provides an easy way to implement typical master data maintenance processes. BPM4MDM can be used to establish and standardize maintenance processes without integration gaps.

1.5. Storyflow Summary

Scene 1: Request a new product In this scene a new product is requested. The scene walks through the complete creation process with one rework step. The product is created in the dashboard and rejected by the approver. After a rework step the request is approved. The following features of the process will be explained:

Dashboard – search form, result list, product details

Product View – how can it be changed by configuration

Validation of entered data

Show the task in the UWL of the appropriate approvers and show the email notification

Demonstrate the approver determination by changing the category in the rework step

Syndication

How the intermediate event works

Checkin

Scene 2: Cancel a request for changing a product In this scene an existing product is changed. The scene walks through the change process with one rework step. The product is selected in the dashboard and changed. It is rejected by the approver. In the rework step the process is cancelled. Before starting the process the rule for the approver determination is changed on the fly. The following features of the process will be explained:

Changing of rules with the rules manager

The compare functionality in the approval step

Rollback of checked out records

Terminating the process Scene 3: Create a new product as copy In this scene a new product is created as copy of an existing. The scene walks through the creation process without rework step. During checkin an error is provoked. The following features of the process will be explained:

Duplication of records

Error handling

Monitoring of processes


2. TECHNICAL REQUIREMENTS

2.1. Prerequisites

2.1.1. Setting up the Mail Server

If you want to send notifications a mail server needs to be configured that can be reached from the Discovery system. Open the NetWeaver Administrator via the Favorites, login with user demopr, password welcome. Go to Configuration/Infrastructure Open “Java System Properties”, search for mail in the Services Tab and enter the appropriate smtp host. You also have to change the “mail.from” property to an existing mail address on the mail server

2.1.2. Setting up Mail Addresses

In order to receive mails the requestors and approvers you will use during the demo need to be assigned a valid email address. Open the NetWeaver Administrator via the Favorites. Go to Configuration/Security Open “Identity Management”, search for all users that have a name like *demo*. Click “Modify” Change the email address and press “Save”.


2.2. System Access Information

2.2.1. System Landscape

System Landscape this Process is built in CE 7.30 MDM 7.1 BOBJ DS 4.0 Discovery System 5.0

Solution Components used in this Process SAP NetWeaver 7.3 SAP MDM 7.1 SP 06 MDM Web Dynpro Components MDM Web Services

2.2.2. Users

Predefined User Name Belongs to Group Password Role

DemoAD

Approver

DemoDe

com.sap.demo.mdm.products. approvers

welcome

Approver for all categories except those that start with 10,20 or 30, German

DemoAD10 Approver

DemoDe10

com.sap.demo.mdm.products. approvers10

welcome

Approver for all categories that start with 10, German


DemoAD20 Approver

DemoDe20


welcome


DemoAD30 Approver

DemoDe30


welcome


DemoAE

Approver

DemoEn

com.sap.demo.mdm.products. approvers

welcome

Approver for all categories except those that start with 10,20 or 30, English

DemoAE10

Approver

DemoEn10


welcome

Approver for all categories that start with 10, English

DemoAE20

Approver

DemoEn20


welcome


DemoAE30

Approver

DemoEn30



DemoRD Requestor

DemoDe

com.sap.demo.mdm.products. requestors

welcome

Requestor, German

DemoRE Requestor

DemoEn

com.sap.demo.mdm.products. requestors

welcome

Requestor, English

demopr Dee Demo

products

Administrator welcome

only on Discovery System, not on MDM image

Caution: For logging in to portal it doesn’t matter whether upper or lower cases are used, in MDM it

matters! On Discovery system they are maintained in upper case letters.

2.2.3. Languages Supported

Please select the standard languages in which this demo is available (i.e. translated into).

____ English

____ German _____ French _____ Spanish _____ Portuguese _____ Japanese _____ Simplified Chinese _____ Korean


3. DEMO SCRIPT

3.1. Story FloW

3.2. Preparations

1. For firing the intermediate event you need to logon to the Web Service Navigator with administrator rights. Open the Internet Explorer and go to Web Service Navigator via the favorites. Logon with user demopr, password welcome.

Search for the ConfirmSyndication web service (with search type Provider System).

Press next till you reach the step Input Parameters. You will need it later on.


2. For showing the MDM Web Service Generator and MDM Web Dynpro Configuration open the portal in a new browser tab and go to the MDM_Config tab. Select project “DEMO_MDM_ProductsPartners” in the MDM Web Service generator.

Go to the MDM Web Dynpro configurator and select the DEMO_MDM_ProductsPartners project.


3. Open the MDM Data Manager, connect to the repository Products+Partners on server localhost

with user DEMOPR and password welcome. (If it is not in drop down list use the button right on the drop down list and enter localhost as server and choose the repository and confirm).

Caution: User name and password are case sensitive! If you see the data manager main view change to table products with the drop down list.


4. In case that you want to show the BPM process in the NetWeaver Developer Studio (NWDS) open the NWDS (you find the icon on the desktop). Choose workspace WSDemoProducts and change to the Process development perspective and open the process by double clicking MaintainProduct.


5. Open the Rules Manager in a new browser tab and open the Approver Determination rule set

In order to be able to work with the demo users in parallel select “New session” in the “File menu of the browser. There you can open the portal and logon with the demo users.

3.3. Step-By Step Guide

3.3.1. Scene 1: Request a New Product

In this scene a new product is requested. The scene walks through the complete creation process with one rework step. The product is created in the dashboard and rejected by the approver. After a rework step the request is approved.


Step 1.1.1: Dashboard

What to Say By means of the dashboard the user is able to see and search the content of the MDM product repository. From the dashboard the product maintenance process can be started. The screen consists of three major areas: the search area on the left, the result list on the right and the product details area on the bottom. The product details are only shown when a product is selected in the result list. On the top there are three buttons for the possible maintenance activities: create, change and create as copy. The change and create as copy buttons are only enabled when a product is selected in the result list.

What To Do & What You Should See

Log in to the portal userid = DemoR[D/E], password = welcome1 Go to the Dashboard tab, explain the Dashboard

Step 1.2.1: Create Product – Check out as New

What to Say When creating a record a new record is created as checked out. You can verify this in the data manager. When pressing the cancel button or closing the browser window without starting the maintenance process a

1 Choose DemoRD if you want to do your demonstration in German, DemoRE otherwise


rollback is done.


On the initial screen of the dashboard press button create. The product view is shown. Remember the number of the MDM product ID Go to the MDM data manager. A new record marked as checked out with the previously created

product id should be there. If you don’t see the record you have to check the All Versions option on a record (right click on a record for context menu “Check in/out All versions”.

Press the button cancel. Go to the MDM data manager. The new record shouldn’t be there anymore. You can repeat the steps above. Do not press the button cancel but close the browser window,

the record shouldn’t be there anymore as well.


Step 1.2.2: Create Product – How to Configure the Product View

What to Say The content and the layout of all views shown in the dashboard are configured in the Web Dynpro Configurator and can be changed on the fly. We want to put the category on the first place in Product Categorization Tab and mark the product group as mandatory.


Go to the previously started MDM WD Components configurator and edit the ItemDetailsproductsCreate configuration (Action-Edit)

Select Tab Tabs/Trays. Select row Product Categorization. Press button Select Fields, select the Category field and move it up

Select the Tab Field Properties. Select the field Product Group and set the property Required to true.

Save and close the configuration. Restart the dashboard application by pressing the navigation entry in the portal Go to the dashboard and press Create again. You should see the view with the new layout.


Reset the Product Group’s property Required back to false, and Save and Close the configuration.

Step 1.2.3: Create Product – Entering Product Data

What to Say In the product view all data of a product can be maintained. All mandatory fields are marked with a red asterisk. You can validate that all mandatory fields have a value by pressing the button “validate”. The validation is also performed when pressing the submit button. During the validation all fields marked as mandatory are checked and all fields that have a validation configured in MDM.


Login to the portal with user DemoR[E|D] and password welcome. Click on the Dashboard tab. On the initial screen of the dashboard press button create. The product view is shown. Enter data for all fields marked as mandatory except the Base Unit of Measure field

o Product Number: combine the MDM product ID with the date – i.e. 617-20110707 o Product Type: Competitive product o Description: Description for 617-20110707

When you enter a Volume UOM (Tab Product Details) you see a limited list of all units with dimension “volume”. This is a special feature of the MDM WD Components (This Tab will disappear in the next step – so it is important to keep the sequence).

Category (Tab Product Categorization): H21020 – Be aware that parental nodes can´t be used (triangle in front) in hierarchy fields - only leaf nodes (small square in front of node) can be assigned to products. Here you can show, that in case that you choose a sub category from H2 the tabs “Product


Details” and “Product Relations” disappear. By using a sub category of N1 the tabs appear again.

Press validate – you should see two validation errors. That’s because the field Base Unit of Measure is marked as mandatory in the WD Component configurator and additionally there is an MDM validation.

Enter Base Unit of Measure – Pack – you see a very long list of units of measure – it’s the complete content of the lookup table Units. You can also search for the Pack Unit of Measure if it is not visible.

Step 1.2.4: Create Product – Start the Maintenance Process

What to Say The BPM process is started from the Dashboard by calling a web service.


Press button Submit. The process will be started. The approver should receive an email where the outstanding approval is announced


Step 1.3.1: The Approval Step – Universal Worklist (UWL)

What to Say The approver that belongs to the approver group should see the approval task in his work list. We have chosen category H21020. Thus it is one of the approvers DemoA[E|D]. By opening the task the approver claims it for itself.

What To Do & What You Should See Log off from the portal and login with user DemoA[E|D] and password welcome. If the task is not shown click on refresh button in the upper right corner. Notice that the subject contains the product number so that we can distinguish the different tasks. The status of the task is New Click on the subject to open the task Close the browser window The status has changed to In Progress because the approver has claimed the task. The status can be reset to New inside the task in the action menu by choosing Put Back In the action menu you can also delegate the task – but caution, the task might be delegated to

someone who is not an approver. This functionality can also be switched off generally. Clicking the link Maintain Product near process opens the visualization of the process. The current

step is marked with a green dot.


Step 1.3.2: The Approval Step - Reject

What to Say In order to request a rework the approver rejects the request. For rejection he has to enter a comment.

What To Do & What You Should See The product data are shown in read only mode. With the compare button it is possible to see the

changed field values. In case of a new product there will be no changes shown. Enter a comment. Press the button Reject. The task should disappear from the work list of the approver.


Step 1.4.1: Rework Step – Universal Worklist

What to Say The request is passed back to the requestor. He sees it now in his work list. The product data can be changed. After submitting the request it is forwarded to the approver again

What To Do & What You Should See Log off from the portal and log on as user DemoR[E|D]. Open the Universal Worklist, the task should be there.


Step 1.4.2: Rework Step – Make the changes

What to Say The requestor changes the category. When submitting the request the approver determination is called again.

What To Do & What You Should See Click on the subject of the task in the UWL. You see the comment of the approver in the history data. Change the category to 20101015, (Expand node N120201020101020101015) notice that

afterwards the tabs Product Details and Product Relations are visible. Press submit


Step 1.4.3: Rework Step – Approve the Changed Data

What to Say The new approver is now DemoA[D|E]20 due to the change of the category to 20101015.

What To Do & What You Should See Log off from the portal and log on as user DemoA[E|D]20. Open the Universal Worklist, the approval task should be there. Open the task Copy the product number because you will need it in the next step. Press Approve.

Step 1.5.1: Syndicate – Trigger Syndication

What to Say The syndication is an automated activity in the process. It is started by means of an asynchronous MDM Web Service. The syndication is triggered in the MDM repository and will be executed by the syndication server. There is no information about the success of the syndication returned to the calling process. As result of the syndication a file with a specific XML format is created that can be grabbed for instance by PI to transfer it to the backend system. The format of the file is specified by a syndication map.



Nevertheless we can check whether the syndication was working. As result a file is created on the MDM server in the following folder: \\<<your DS V5>>\sapdata\sap\MD5\MDS12\mdm\distributions\MD5_IDB2\Products+Partners\Outbound\R3_ERP\_MDMMatmas\Ready

This file is an XML file that contains all information that needs to be passed to the backend system

?xml version="1.0" encoding="UTF-8"?><MDMMatmas><IDOC><MDME1MARAM><MATNR>627</MATNR><MTART>WETT</MTART><MEINS>PAK</MEINS><MDME1MAKTM><EN>Description 627-20110707</EN></MDME1MAKTM></MDME1MARAM></IDOC></MDMMatmas>

Step 1.5.2: Syndicate – Confirm Syndication

What to Say Somehow the process instance needs to know when the data was successfully transferred to the backend. In case of a new product the external product number has to be written to the MDM as remote keys (for key mapping). When the data were successfully transferred to the backend an intermediate event has to be triggered to let the process know that it can proceed. For the demo scenario we have no real backend. That’s why we call the web service that triggers the intermediate event manually.


Go to the web service navigator that you have opened in advance and enter the product number that you have copied during the rework step and an external product number Caution: Use the same product number – the right process instance is identified by the BPM framework by means of the product number – correlation condition. If you enter another one nothing will happen, also when calling the web service a second time with the same product number. Be aware that this step is only importing Remote Keys for NEW products. In case of product change nothing will happen here.

Click next and the process will proceed. May be you have to enter the credentials of user demopr with password welcome


Step 1.6.1: Finish the Process – Update Key Mapping

What to Say After transferring the product data to the backend a new product has to be enhanced by its key mapping because all subsequent syndications for this product will need the external product number to identify the product in the backend. Updating the key mapping is performed by an automated activity that calls a MDM web service.


You can check that the key mapping was created successfully in the MDM Data Manager. Open the MDM Data Manager, connect to the repository Products+Partners on server localhost with user

DEMOPR and password welcome. (If it is not in drop down list use the button right on the drop down list and enter localhost as server and choose the repository and confirm).

Right click on the record and select Edit Key Mapping in context menu. You should see one entry for R/3 ERP system with the product number and the external product number that you have passed during the web service call for firing the intermediate event.

Step 1.6.2: Finish the Process – Check In

What to Say At least the new product is checked in by an automated activity that calls an MDM Web Service. Because in this and the previous steps generated MDM web services were used it’s a good opportunity to show the MDM Web Service Generator.


Just show the checked in record in the Data Manager


Logon to Portal with user demopr / welcome and switch to tab MDM_config. Click on WSGenerator.

Select the project DEMO_MDM_ProductsPartners, click on Edit, click Log On to MDM Server without password and enter the credentials for the repository (demo/welcome) -> click Next

You see here that web services for all necessary MDM activities can be generated


Step 1.6.3: Finish the Process – Sending the Success Notification

What to Say Finally the requestor gets an email that the maintenance of the product was successfully finished.


3.3.2. Scene 2: Cancel a Request for Changing a Product

In this scene an existing product is changed. The scene walks through the change process with one rework step. The product is selected in the dashboard and changed. It is rejected by the approver. In the rework step the process is cancelled. Before starting the process the rule for the approver determination is changed on the fly. Changes made in the rules manager can be merged easily in the rules project in NWDS by importing them from the rules repository.

Step 2.1.1: Approver Determination – The Rules Manager

What to Say The approver will be determined by the group of approvers that is responsible for the approval of the chosen product category. It is implemented as a business rule. According to changing business requirements business rules can be changed on the fly in the rules manager tool. We will show that our changes apply during the approval step in the process.


Go to the rules manager that you have opened in advance. Alternately, open the rules manager from browser favorites and log in using demopr/welcome. Select the row rules for demo.sap.com. Click on Open Project button (Active Version).

Open the Decision Table ApproverDeterminationDT and change the group to com.sap.demo.mdm.products.approvers

Press the Upload button Check the Activate check box and press Submit Changes The changes should now be active


Step 2.2.1: Start Process for Changing a Product

What to Say In the Dashboard we select a product with category 20… (the category we changed the rule for in the previous step). We change the maintenance status and start the process.


Logon to portal as DemoRE with password welcome. Select in Dashboard the product with product number M10000912 and press button Change Change Maintenance Status to “Change required” Press button Submit


Step 2.2.2: Start Process – Product is Checked Out

What to Say The product is checked out.


Go to MDM data manager and find product M10000912 It should be marked as checked out.


Step 2.3.1: Approval Step - UWL

What to Say According to the change of the business rule performed in the first step approvers of the group “com.sap.demo.mdm.products.approvers” should have the approval task in their work list.


Log off from the portal and logon with user DemoAE and password welcome The new task for product M10000912 should be shown in the work list.

Step 2.3.2: Approval Step – Open Task

What to Say After opening the task the approver can have a look to the changes by pressing the button Compare with Original. In order to cancel the process he has to reject and to ask the requestor to cancel.

Open the task Press the button Compare with Original. You should see the change made in the previous step

(Maintenance Status) Close the popup Enter a comment and press button Reject


Step 2.4.1: Cancel Process

What to Say The requestor gets the request in his UWL. After cancelling the product should be shown as checked in without changes. The requestor gets no notification about the cancellation. Don’t forget to reset the changes to the rule for the next scenario.



Log off from the portal and logon with user DemoRE and password welcome The rework task for product M10000912 should be shown in the work list. Open the task Enter a comment and press button Cancel


3.3.3. Scene 3: Create a New Product as Copy

In this scene a new product is created as copy of an existing. The scene walks through the creation process without rework step. During check in an error is provoked. The following features of the process will be explained:

Duplication of records

Error handling

Monitoring of processes

Step 3.1.1: Create New Product as Copy

What to Say A new product is created as copy of an existing one. Therefore in the dashboard a product has to be selected. Technically the creation as copy means that the record is duplicated and checked out afterwards.


Log on to the portal as user DemoRE with password welcome and go to the dashboard

Select product with number M10000274

Click Create as Copy Note that in the product view all fields are filled with data of product M10000274 except the product

number, enter a new product number like 605-20110711 (MDM Product-YYYYMMDD) Press submit to start the approval process In the data manager a new record is shown as checked out, note that there the original product

number is still visible because the record was created by duplication with a subsequent check out.


Step 3.2.1: Approve the Creation

What to Say Since we have created a product belonging to category 20… an approver of the respective group has to approve


Log off from the portal and log on as user DemoAE with password welcome and go to the work list. Caution: It should be user DemoAE20 from group com.sap.demo.mdm.products.approvers20, but we have changed the approver determination rule in the previous scene.

You should see a task for the newly created product Open the task and approve

Step 3.3.1: Process Monitoring – Open in NWA

What to Say After approval we’ll check our process instance in process monitoring.


Go to the NetWeaver Administrator (NWA) that you have opened in advance Go to Operation – Processes and Tasks Click Manage Processes

Step 3.3.2: Process Monitoring – Find the Process

What to Say With process monitoring the current status of every single process instance can be monitored. First we have to find the instance of our process.


Open the advanced search mask by clicking the Advanced link in the right corner beneath the icons for refresh filter, hide etc.

Enter the current date in Started From/To field, set error status to OK, set Status to In Progress Click Go to search for processes that match the search conditions You find the right process by the start time and the subject


Step 3.3.3: Process Monitoring – Inspect Details of the Process

What to Say After finding the right process you can show which activity is just performed by the process instance and what data are stored in the process context.


To show the process flow click on Show Process Flow The current activity is marked with a green dot. We see that the automated activity of syndication was

performed already. The process instance is waiting for the intermediate event that confirms that the data were successfully sent to the backend.

You see which context data objects are filled You can inspect the context of the process instance in the Context tab. Select the context to show in

the drop down list


Step 3.4.1: Error Handling – Provoking an Error

What to Say Since we have only a simple demo scenario and not a full featured implementation there is only a very rudimentary error handling in the process. Only for the last automated activity (check in) we check the result of the called web service. Normally this has to be done for every single web service call and the errors have to be handled properly so that process can terminate properly and a person is notified that can take care of possibly checked out records etc. We can provoke an error by just checking in the respective record. The web service for checking in will then run into an error.


Go to the MDM Data Manager Find the previously created record First join the checkout and the check in

Step 3.4.2: Error Handling – Fire the Confirm Syndication Event

What to Say Since the process instance is waiting for the intermediate event we have to fire it from the Web Service Navigator.


Go to web service navigator that was opened in advance Enter the parameters for the ConfirmSyndication Web Service (the product number of the newly

created product and the external product number)


Press Next to call the web service

Step 3.4.3: Error Handling – How was the Error Handled

What to Say Since the process instance has no knowledge about the reason why the check in failed an email is sent to the administrator with information about the affected product and the error message that was returned by the web service. Errors should be the exception so that we expect that the administrator can handle the error manually by checking the logs and the system.


You should receive an email with a notification that the check in failed The process should be completed. You can check this in process monitoring

bpm-mdm demo script - archive...4 ©sap deutschland ag & co.kg 2011 1. demo script overview 1.1....

Documents