InfoSphere MDM Collaboration Server V10.0 design strategy and implementation, Part 1: A guideline using a sample business case

This article covers development techniques from writing the design specification to actual implementation. It includes solutions for building a robust and seamless product management IT infrastructure using IBM® InfoSphere® MDM Collaboration Server v10.0. This article considers a sample business case scenario, and then explains how to implement an application using IBM InfoSphere MDM Collaboration Server.

Supal Chowdhury (supal.chowdhury@in.ibm.com), IBM Accredited IT Architect, IBM

Photo of author Supal ChowdhurySupal is IBM Advisory IT architect in application discipline and has more than 13 years of relevant experiences in the field of Information Technology with a sound understanding and knowledge of software development process. His focused technical domains are Portal, CDM and CDI, EI. He has designed, developed, tested and advised client on various elements of a technical solution required by the client. He has applied specialized knowledge to analyze, design, construct, test and implement solutions which addressed complex business or technical requirements.



Divakar Maddikera (divakar.maddikera@in.ibm.com), IT Specialist, IBM

Author photo of Divakar MaddikeraDivakar is a IT specialist with more than six years of well-honed experience in designing, developing, and programming in IBM MDM (Master Data Management - Customer and Product) technologies. He brings with him software development experience in the Retail Industry, and sound knowledge in FMCG (Fast Moving Consumer Goods) business.



06 September 2012

About this article

This two-part series is designed for data architects, designers, and developers who want to begin working on IBM InfoSphere MDM Collaboration Server V10. The series examines how IBM MDM Collaboration Server makes it easy to design and build a product information management solution for a sample business case scenario. It might sound like a huge task, but do not worry, this article breaks it down into manageable parts.

Part 1 of this series lays out the scope for the series, describes the system requirements, introduces the product used for building the application, considers the sample business case scenario, and describes the technical design specification using best practice with MDM Collaboration Server V10.

Part 2 focuses primarily on integral development strategy and best practices to build the application. The design specification for the business case scenario is well detailed in Part 1. This part also deals with some significant development steps based on the development strategy described, as well as troubleshooting techniques.

In short, the series lets you connect each section of the series to help you build hands-on knowledge with IBM MDM Collaboration Server.


Objectives

IBM MDM Collaboration Server implementation and development can be challenging for the beginner, so this series will help you start with implementing the basic concepts of IBM MDM Collaboration Server.

The objective of this article is to help you easily implement an application with MDM Collaboration Server environment, including the following main points.

  • Adhering to the system requirements for building MDM Collaboration Server based application
  • Understanding a very high-level view of the product
  • Knowing the basic implementation process for building MDM Collaboration Server based solution by means of the following:
    • Defining a sample business case scenario of retail industries with the Collaboration Server concept
    • Best practices for writing design specification for MDM Collaboration Server, based on the sample case

Prerequisites

This series of articles is written for architects, designers, and developers with an interest in learning more about application implementation using IBM InfoSphere MDM Collaboration Server V10.0. The target audiences are expected to have the following skills.

  • Experiences and skills in Java/ J2EE
  • Familiarity with IBM InfoSphere Master Data Management Server
  • Familiarity with the basics of retail industries and product information management
  • Familiarity with any IDE, such as IBM Rational Software Application Developer, Rational Software Architect, and Eclipse as the development platform

System requirements

This series of articles (Part 1 and Part 2) is designed to be run in an environment consisting of a laptop/desktop with the following setup to host an InfoSphere MDM Collaboration Server.

  • 3GB of memory or more
  • 10GB free disk space
  • AIX, Solaris, Linux OS with a newer version on which InfoSphere MDM Collaboration Server V10.0 can be installed. Note: These articles may also work with previous versions of the product, but the scenario has not been tested with them.

For development environment:

  • IDE (Eclipse or IBM Rational Software Architect or IBM Rational Application Developer) should be installed in your local machine.

Introduction

This series will provide brief description of each section of the article along with its scope and de-scope. This article is intended to provide an end-to-end proof of technology (PoT) by considering a sample case scenario.

Software installation considerations

This article does not cover the details of the IBM MDM Collaboration Server installation environment. It is assumed that the prerequisite system requirements are ready to start with this PoT. For more information see the InfoSphere Master Data Management Collaboration Server Version 10.0.0 Information Center in Resources section.

This section covers the following areas.

  • Product overview and its architectural components.
  • Business case: A sample business case of retail industries with MDM Collaboration Server concept.
  • Designing best practices: Best practices for writing design specification for MDM Collaboration Server, based on the sample business case.

High-level product view

IBM InfoSphere MDM Collaboration Server at a glance

IBM InfoSphere MDM Collaboration Server version 10.0 offers various features that help organizations manage their ever-changing enterprise product data. It provides users with a 360-degree view of products, services, and hierarchies. It also supports enterprise-wide business process collaboration on product information. The security model provides role-based granular access with multiple dimensions of control. It helps an enterprise to build a highly scalable and reliable IT infrastructure on a product information management platform.

IBM MDM for Collaboration Server Architecture leverages the following, as shown in Figure 1.

  • Blend of Java 2 Platform, Enterprise Edition (J2EE) architecture.
  • Support for vertical and horizontal clustering.
  • High user concurrency.
  • Capacity for managing large data, such as number of products, number of attribute per product, and rich media through batch processing.
  • GUI optimized for power users as well as business users.
  • Support for various data formats and communication protocols, such as FTP, MQ, HTTP, SOAP, and JMS.SMTP.
  • UI Driven Product Data Transformation Enablers to enable feeds and syndications seamlessly.
  • Easy integration with leading enterprise application integration tools, through messaging infrastructure.
  • Certified connectivity for industry-leading data pools.
  • Programming interfaces supported, such as MDM Collaboration Server V10.0 Scripting and JAVA API.
Figure 1. MDM Collaboration Server solution architecture
This figure shows MDM Collaboration Server Solution Architecture

Business case to consider

This scenario assumes a fictitious leading food retailer company named FictXYZ Inc. This is a major food retailing chain, and is built upon a heritage of providing customers with healthy, safe, fresh, processed and tasty food. FictXYZ is doing their business on more than 100 different food products in 50 different stores in the United States.

FictXYZ's business is governed by their existing product data managed by the legacy IT infrastructure. All food products data are managed by disparate exiting legacy systems. The company is focusing a strong ethical approach to business and continuous leadership and innovation by building a smarter IT system.

Company business problems

  • Purchasing, Marketing and Customer Services of FictXYZ Inc. are currently using different existing old and legacy end-point systems data in order to maintain their food-product information, which is currently causing inconsistencies in item definition, product assortment, and business process.
  • New types of food products are introduced by numerous manufacturers, which have resulted in shorter life span, and shorter time to market.
  • The inability to manage food-product categories and specific features has caused marketing to maintain technical information in different handy and risk-prone data storages such as Excel spreadsheets.
  • These issues cause the following pain points for businesses.
    • Inconsistencies in the item master definition to manage food-product.
    • Time taken to introduce a new product and decommissioning of old product.
    • Lack of data governance.
    • Lack of data validation.
    • Inter-department approvals and enrichments.
    • Inability to enrich food item specification.

Existing business data model

An existing business model is based on a product-oriented model wherein a company business unit (BU) is formed and appeared in a way so that it represents a single business with multiple units within the FictXYZ Organization Unit (OU).

FictXYZ owns Product (Food) Management Group as a Product Management OU which has the following core business units, as shown in Figure 2 and Figure 3.

  • Fresh food
  • Processed food
Figure 2. FictXYZ's business unit (Fresh Food Category) in a hierarchical representation
This figure shows business unit of fress food
Figure 3. FictXYZ's business unit (Processed Food Category) in a hierarchical representation.
This figure shows business unit of processed food

Each Food Product is associated with the following item nutritious properties, as shown in Table 1.

Table 1. Item nutritious properties
#Nutritious propertiesDescription
1ProteinIt is contained in meat and fish
2Saturated fatAnimal fats such as cream, cheese, butter, and ghee; suet, tallow, lard, and fatty meats; as well as certain vegetable products such as coconut oil, cottonseed oil, palm kernel oil, chocolate, and many prepared foods contains saturated fat.
3Polyunsaturated fatsPolyunsaturated fat normally is found normally in nuts, seeds, fish, algae, leafy greens, and krill.
4Vitamin AVitamin A is found naturally in many fresh foods like carrots, liver, sweet potato, butter, broccoli, etc.
5Folic acidGrain products are fortified with folic acid.
6Vitamin BVitamin B is found in whole unprocessed foods.
7IronMeat, poultry, and fish are the best sources for Iron.
10Vitamin DPure cod liver oil is a good source of Vitamin D.
11CalciumFood Sources of Calcium like yogurt, orange juice, milk.
12CarbohydrateCarbohydrates are found in many common foods like potato chips, rice, breads, pasta, cookies, fruit, vegetables and cereals.
13Vitamin CSweet red pepper, strawberries, and oranges are prime sources of Vitamin C.
14FiberGood sources of fiber include wholegrain foods, and fruits and vegetables.
15Vitamin ESunflower seeds, almonds, pine nuts, and peanuts are main sources of Vitamin E.
16SugarSources high in sugar include apricots, pineapple, plums, cherries, blueberries, and honey.
17SaltAlmost every food contains salt.

Existing business security management

FictXYZ Inc has security management that defines users, and some rules which are executed by users with different roles, as shown in Table 2.

Table 2. Users role relationship
#User nameNameRolesDescription
1AdMacMacVP approval roleThe vice president for the product management is for all approval and rejection of product introduction and enrichment.
2BuySDasSDasProduct specialist roleThe product specialist is liable for enriching the product item.
3VPChouhanChowhanMarketing people roleInitiates item creation
4AdminKabAdmin roleThis role has all privileges

Note: One role can have multiple users.

Rules of visibility/accessibility for users

This is used to set the permissions for which users can view/edit individual containers. This is associated with roles. In FictXYZ Inc, there are two groups namely ACG1 and ACG2. ACG1 is used to set the permission for view of individual catalogs. ACG1 contains all users by default. ACG2 is used to set the permission for edit of individual catalogs. ACG 2 has three users called AdMac, Admin, BuySDas.

Existing business process

The company has product management that leverages the following business process activities.

  • New launched product introduction.
  • Product maintenance.

The business process workflows are as follows.

  1. A new product has been introduced: The new product introduction is processed by the following fine-grain services.

    • Initiate the product.
    • Classify or enrich the product.
    • Approve the product to be published in market.
  2. The process to maintain the products: The market published product is now required to enrich. This business process contains the following fine-grain services.

    • Search the product to modify.
    • Enrich the product.
    • Approve the same.

Note: The number of users and their roles are assigned in those workflows.

Existing business vendors

The company does business with the following vendors who supply different food products, as shown in Table 3.

Table 3. Vendor and corresponding products
VendorProducts
ABC Apples Inc.Custard apple
MNO Fruit Inc.Dry fruit
XYZ SupplierFresh chicken
LM Fish SupplierFish fillets

Solution

To build a smarter IT system for FictXYZ Inc., where all existing disparate systems data will be placed in a single point so that the product information can be viewed in 360 degree style, the company will tie up with the following complete IT solution.

The IBM MDM Collaboration Server V10.0 solution is to target the consolidation of master data to ensure data consistency, as well as the implementation of a validation framework, workflows, and standardized business processes. The solution scope and objectives include the following.

  • Application implementation using IBM MDM for Collaboration Server tool.
  • Food-product specification will be defined.
  • Food-product information will be imported from different FictXYZ legacy systems, such as upstream systems, via CSV file to the Collaboration Server repository.
  • Search product data efficiently.
  • Use workflow to improve product introduction and enrichment.
  • Solution also facilitates exporting Collaboration Server data to a CSV file to fulfill downstream systems, such as FictXYZ eCommerce needs.

Solution benefits

Major anticipated benefits towards FictXYZ Inc., and applying the solution using IBM MDM Collaboration Server include the following.

  • Increase efficiency of new product introduction, item enrichment process.
  • Shortening time for new product introduction (NPI).
  • Reduce error and improving overall data quality.
  • Single point of product information.
  • Consistent, unified and normalized data across the FictXYZ IT systems.
  • Extensible data model for MDM Collaboration Server.
  • Avoid lost productivity, such as manual cleansing per SKU per year.

Designing best practice that consider the business use case

The best approach for designing the Collaboration Server implementation, after considering the business scenario mentioned previously is to build a smarter system named FictXYZ smarter merchandise system.

The design specification will rigorously define what the prime sections are, with the best practices that are needed to be there for Collaboration Server-based implementation of FictXYZ smarter merchandise system, and what the content of each section is. For designing the FictXYZ smarter merchandise system, the following points are required for developers to implement Collaboration Server-based FictXYZ smarter merchandise system solution.

Solution architecture

Figure 4 shows the FictXYZ smarter merchandise system high-level technical solution architecture diagram.  Catalogs and Hierarchies and Workflows could also be in one group, while Users/Roles and Custom Tools could be in a separate box. The export should have a mass load to load the system initially.

Figure 4. Solution architecture
This figure shows Solution Architecture

Legacy system and eCom considerations

Details of the FictXYZ Legacy systems and eCommerce application is out of scope of this PoT.

System context model

Figure 5 shows the FictXYZ smarter merchandise system high-level system context diagram.

Figure 5. High-level system context
This figure shows the system context diagram

The core of the FictXYZ smarter merchandise system is interfaced by several upstream/downstream systems. The individual system is accessed by the FictXYZ access control group, and is made up of several users.

Component data model

The FictXYZ Inc. product hierarchy is shown in Figure 6.

Figure 6. Product hierarchy
This figure shows FictXYZ Product Hierarchy

Products are categorized into four levels. The fourth level stores the product (item) data.

  • Level-1 Fresh food, processed food
  • Level-2 Veg, non-veg
  • Level-3 Vegetable salad, fruit, floral, meat. Unit sub category
  • Level-4 Apple, Banana. Chicken, Turkey, Duck. Unit category)

MDM Collaboration server component model

The MDM Collaboration Server V10.0 data model for FictXYZ smarter merchandise system is shown in Figure 7.

Figure 7. Component model
This figure shows Component Model

Detail design of component model

MDM Collaboration Server implementation requires seamless and robust meta data design based on MDM Collaboration Server component model concept. Figure 7 shows the components which are the prime needs in order to create MDM Collaboration Server application for FictXYZ smarter merchandise system.

Catalogs

The following is the specification of catalog components that are discussed in Part 2.

  • Name: FictXYZ Product Catalog.
  • Description: This is a container to hold FictXYZ product items data as MDM Collaboration Server Item entities.
  • Purpose: This catalog will be used to store the product items for FictXYZ smarter merchandise system.
  • Primary spec: FictXYZ Product Ctg Spec.
  • Secondary spec: N/A.
  • Primary hierarchy: FictXYZ Product Hierarchy, used to categorize the products.
  • Access control group: Default.
  • Associated collaboration areas:
    • New FictXYZ product collaboration area, with workflow name of New FictXYZproduct WF, used to create the FictXYZ product item in the catalog.
    • Modify FictXYZ product collaboration area, with workflow name of Modify FictXYZproduct WF, used to modify the FictXYZ product item in the catalog.

Specifications

The design of each specification of the component model for FictXYZ smarter merchandise system is shown in Table 4, which is discussed in more detail in Part 2.

  • Name: FictXYZ Product Ctg Spec.
  • Type: Primary specification.
  • Description: It is primary specification for FictXYZ Product Catalog.
  • Where used: Using in FictXYZ Product Catalog.
  • Purpose: To describe the product item attributes.

The details of the specification 1 are as follows.

  • Name: FictXYZ Product Ctg Spec.
  • Type: Primary specification
  • Description: It is primary specification for FictXYZ Product Catalog.
  • Where used: Using in FictXYZ Product Catalog.
  • Purpose: To describe the product item attributes.
Table 4. Specification - 1 attribute details
Attribute name Attribute type PK Idx Min  occurrence Max occurrence Length
Item code String yes yes 1 1 10
Item description String no no 0 1 50
Item status String no yes 0 1 20
Expiry date Date no no 1 1 40
Vendor ID Integer no yes 0 1 10
Vendor description String no no 0 1 50
Department code Integer no yes 0 1 10
Subclass code Integer no yes 0 1 10
Net weight Number no no 0 1 10
Warehouse code Integer no no 0 1 10
Item nutrition ID Lookup table no no 0 1 10
Item nutrition description String no no 0 1 50
Audit/created on Date no yes 0 1 40
Audit/last modified on Date no no 0 1 40
Audit/last modified by user ID String no no 0 1 20
Audit/last modified by user name String no No 0 1 50

The following shows the design details for specification - 2 for FictXYZ smarter merchandise system.

  • Name: FictXYZ Product Hier Spec.
  • Type: Hierarchy Primary Spec.
  • Description: It is primary spec for FictXYZ Product Hierarchy.
  • Where used: Using in FictXYZ Product Hierarchy.
  • Purpose: To describe the categorized attributes.

Table 5 shows the attribute details for specification 2.

Table 5. Specification - 2 attribute details
Attribute name Attribute type PK Idx Min  occurrence Max occurrence Length
Code Integer yes yes 1 1 10
Display String no no 0 1 20
Audit/created on Date no no 0 1 40
Audit/last modified on Date no No 0 1 40

Table 6 shows the design details for specification - 3 for FictXYZ smarter merchandise system.

  • Name: FictXYZ Lookup Spec.
  • Type: Lookup Specification.
  • Description: Item nutrition lookup.
  • Where used: Item nutrition lookup table specification.
  • Purpose: Describes the nutrition of the items.
Table 6. The details of specification - 3
Attribute name Attribute type PK Idx Min  occurrence Max occurrence Length
Key Integer yes yes 1 1 10
Value String no no 0 1 50
Attribute1 String no no 0 1 40
Attribute2 String no no 0 1 40

Multi-occurrence attribute consideration

An attribute with multi-occurrence demonstrates MDM Collaboration Server flexibility. But to simplify the MDM Collaboration Server implementation in Part 2 of this article series, multi-occurrence attributes are not considered.

Hierarchies

The following shows the design of each hierarchy model, but this is discussed more fully in Part 2 of this article series.

  • Hierarchy name: FictXYZ Product Hierarchy.
  • Hierarchy type: Category.
  • Purpose: A hierarchy that contains four levels is created to categorize the FictXYZ products.
    1. Business units (fresh food and processed food)
    2. Food categories (vegetables and non vegetables)
    3. Unit categories (fruits, floral, meat, poultry)
    4. Unit sub-categories (apple, banana, cut flowers, beef, lamb, chicken, turkey)
  • Max levels: 4.
  • Primary key: Product Ctg Spec/code.
  • Display attribute: Product Hier Spec/display.
  • Primary specification: FictXYZ Product Hier Spec.
  • Associated secondary specifications: NA
  • Associated catalogs: FictXYZ Product Catalog: A Collaboration Server catalog container that is responsible for storing FictXYZ product items data as Collaboration Server item entities.
  • associated collaboration areas: New FictXYZ Product Collab Area, modify FictXYZ Product Collab Area.
  • Views: All, used to edit the attributes data.
  • Access control group: Default.
  • Hierarchy creation decision: Using IBM MDM Collaboration Server V10.0 UI Administrator.

Attribute collections

The attribute collections, as follows, are needed to indicate that these attributes work inside a workflow step.

  • Name: FictXYZ Product Item AC
  • Description: These attribute collections are defined to work inside the initiate workflow steps for both new product and maintain product workflows. Includes all attributes that belong to the FictXYZ Product Ctg Spec specification.
  • Related entities: New FictXYZ Product Workflow, modify FictXYZ Product Workflow.

Lookup tables

The following are the design details of the lookup tables.

  • Lookup table name: Item Nutrition Lookup.
  • Description: This lookup table requires the key value pair of food properties which are contained inside each kind of food. For example, protein is contained in meat and fish.
  • Related entities: FictXYZ Product Ctg Spec
  • Lookup table specification: FictXYZ Lookup Spec.
  • Type: Single string key(key-value).
  • Volumes:
    • 18
    • key-value
    • 1 - Protein 
    • 2 - Saturated fat
    • 3 - polyunsaturated fats
    • 4 - Vitamin A
    • 5 - Folic acid
    • 6 - Vitamin B
    • 7 - Iron
    • 8 - Vitamin D
    • 9 - Calcium
    • 10 - Iron
    • 11 - Calcium
    • 12 - Carbohydrate
    • 13 - Vitamin C
    • 14 - Fiber
    • 15 - Vitamin E
    • 16 - Sugar

Data mapping

Note: MDM Collaboration Server supports the following types of mapping.

  1. Catalog specification to destination specification (CS-DS).
  2. Catalog to catalog (C-C).
  3. Catalog to destination specification(C-DS).
  4. File specification to catalog (FS-C).
  5. File specification to catalog specification (FS-CS).

Table 7 shows the FictXYZ smarter merchandise system requires one mapping, such as FictXYZ CSV file to product mapping.

Table 7. FictXYZ smarter merchandise system mapping
Source Target Kind

FictXYZ legacy product file specification.

FictXYZ Product Catalog specification.

FS-CS

Users and roles

FictXYZ project management of users within MDM Collaboration Server is controlled through a set of roles. Privileges are not set to the individual, rather to the role that they are assigned to. You can create users and customized roles, such as Admin Role, VP Approval Role, and others, with permissions to specific MDM Collaboration Server functionalities for the users.

User definitions and settings

FictXYZ project users can be represented by a very broad spectrum of skills, roles, and privileges, from system administrator to an end user with limited access to data and functionality, as shown in Table 8.

Table 8. The details of user definitions for FictXYZ smarter merchandise system
User ID User name Purpose, roles, and responsibilities

AdMac

Mac

VP Approve_Role (To approve the item when data is satisfactory,  reject otherwise).

BuySDas

SDas

Product_Specialist_Role (To update and classify item).

VPChouhan

Chowhan

Marketing_Role (To initiate item creation).

Admin

Admin

Admin_Role (all privileges).

Roles

All role information for the products is as shown in Table 9.

Table 9. The details of roles for FictXYZ smarter merchandise system
Role name Container related functionality access Role description

Admin_Role

List

View items

Add items

Clone items

Modify items

Re-categorize items

summary items

Search

Run preview script

Admin role has all full access to the system.

VP Approval_Role

List

View items

Re-categorize items

Summary items

Search

Run preview script

VP Approval_Role has the privileges to approve or reject any enrichment of the product item.

Marketing_Role

List

View items

Add items

Clone items

Marketing_Role has the privileges to create items in collaboration areas, and can view the items but do not have  system configuration access.

Product_Specialist_Role

List

View items

Modify items

Re-categorize items

Search

Product_Specialist_Role has the privileges to update the item in collaboration areas, and this role can view the items but  do not have system configuration access, such as Spec, Roles, ACG, and others.

Access control group

Rules of visibility of FictXYZ's business can be achieved by creating powerful access control groups (ACGs). An MDM Collaboration Server concept that combines roles to a single source in order to serve as a liaison between role permissions and MDM Collaboration Server objects. As part of the data model for FictXYZ smarter merchandise system, the 'Default' as ACG is considered.

Business process collaboration

In order to define the business process collaboration for FictXYZ smarter merchandise system, consider the following sequence of designing rules.

  • The business process needs to have associated collaboration areas which are nothing but a composition of workflow and catalog or hierarchy.
  • The workflow is the sum of the food-product workflow steps tied together.
  • The workflow steps are the combination of workflow name, workflow step type, product attributes, and user/role.

This section describes how FictXYZ smarter merchandise system implements the business workflows along with detail design of the business process after following the previous rules.

Workflow 1: FictXYZ creates product work flow

Figure 8 shows the workflow for the business process for new product introduction.

Figure 8. FictXYZ create product workflow design
This figure shows workflow for a new product

Create item

Item creation is initiated and verified by a user who has a marketing role, such as VPChouhan, and it must be verified to be a new product. Once the item is created, it goes to enrich item and is classified as an item step.

The following shows the details for creating the item.

  • User visibility step name: Create item.
  • Associated workflow: FictXYZ Create Product WF.
  • Container: FictXYZ Product Catalog.
  • Step type: General.
  • Participant's role (performers): Marketing people.
  • User drive to step: VPChouhan (marketing person initiates the item creation).
  • Description: VPChouhan user has the privilege to create the item in a new FictXYZ Product Collab Area.
  • Available exit choices: DONE - The user will choose DONE if all data is satisfactory. The user may enter the base pack attribute comment prior to choosing DONE.
  • Editable attributes: Item description, item nutrition ID, item status.
  • Validations: When a user provides the item nutrition ID value from lookup table, the item nutrition description value gets automatically populated.
  • Next steps: Enrich item, classify item.

Enrich item

In this step, the core attributes such as the full textual description on the product like vendor ID, warehouse code, and net weight expiry date of the new product are updated by the product specialist. This step may contain parallel processes performed by the user, such as BuySDas. The following shows the details for enriching an item.

  • User visibility step name: Enrich item.
  • Associated workflow: FictXYZ Create Product WF.
  • Container: FictXYZ Product Catalog.
  • Step type: General.
  • Participant's role (performers): Product Specialist.
  • User drive to step: BuySDas (a product specialist will update the required attributes fields).
  • Description: BuySDas user has the privileges to modify the item in the new FictXYZ Product Collab Area.
  • Available exit choices: DONE - The user will choose DONE if all data is satisfactory. The user may enter the comment (Base Pack attribute) prior to choosing DONE.
  • Editable attributes: Expiry data, vendor ID, vendor description, department code, warehouse code, net weight.
  • Validations: N/A
  • Next steps: Approve.

Classify item

After the item has been created and enriched with its core attributes, the item is typically classified into one or more hierarchies. These hierarchies can include buyer or sales channel specific hierarchies, all of which support specific functions within an organization. After an item is classified, a separate enrichment process is frequently required to enrich category specific attributes, if they exist. A category manager or an item specialist, such as BuySDas, usually performs this step, and can also be automated in the appropriate situations. The following shows the details for classifying an item.

  • User visibility step name: Classify.
  • Associated workflow: FictXYZ Create Product WF.
  • Container: FictXYZ Product Catalog.
  • Step type: General.
  • Participant's role (performers): Product Specialist.
  • User drive to step: BuySDas (product specialist person will hierarchy in this step).
  • Description: BuySDas users have the privileges to give item hierarchy in  new FictXYZ Product Collab Area.
  • Available exit choices: DONE - The user will choose Done if all data is satisfactory. The user may enter the comment (base pack attribute) prior to choosing Done.
  • Editable attributes: Fresh food attributes.
  • Validations: N/A
  • Next steps: Approve.

Approve, reject, or rework

The final step in the process is the approval/rejection step. This step can involve the VP of product management (AdMac) to lead this activity.

The legacy data needs to be introduced, classified, and enriched by users followed by approvals by the VP. First you need to load the data objects to the collaboration area (intermediate process). Once validation, enrichment and mediations are done, the item gets saved in the FictXYZ Product Catalog. The collaboration area for this business process is New FictXYZ Product Collab Area.

To build the MDM collaboration server workflow, the collaboration area for New Product Introduction requires following design consideration along with properties and mandatory steps, shown as follows.

  • User visibility step name: Approve.
  • Associated workflow: FictXYZ Create Product WF.
  • Container: FictXYZ Product Catalog.
  • Step type: General.
  • Participant's role (performers): VP approval role.
  • User drive to step: AdMac (the VP will approve item after checking details, and can correct the item code also if required).
  • Description: AdMac users have the privileges to approve the item in new FictXYZ Product Collab Area. This is the last step of the workflow.
  • Available exit choices:
    • APPROVED - The user will choose Success if all data is satisfactory.
    • REJECTED: The user will choose Fail if all data is not-satisfactory.
  • View: All food product attributes.
  • Editable attributes: Item code is editable. The approver can change the item code value if required.
  • Validations: N/A.
  • Next steps: N/A.

Workflow 2: FictXYZ enrich product workflow

This is the workflow for the business process for product enrichment, as shown in Figure 9.

Figure 9. FictXYZ enrich product workflow design
the new product workflow for maintain a product

Search and identify item in the catalog

The product specialist user can check out the item from the catalog into collaboration when he wants to update or modify the item data. The BuySDas user will perform a search against all active or inactive items in the catalog to identify an item for modification.

Modify item

Once the item is checked to collaboration, the product specialist user is permitted to modify the data they are responsible for, including updating the related attributes and category is shown as follows.

  • User visibility step name: Modify item.
  • Associated workflow: FictXYZ Create Product WF.
  • Container: FictXYZ Product Catalog.
  • Step type: General.
  • Participant's role (performers): Product Specialist.
  • User drive to step: BuySDas (product specialist will update required attributes fields and category also).
  • Description: BuySDas users have the privileges to modify item in new FictXYZ Product Collab Area.
  • Available exit choices: DONE - The user will choose Done if all data is satisfactory. The user may enter the comment (base pack attribute) prior to choosing Done.
  • Editable attributes: Expiry data, vendor ID, vendor description, department code, warehouse code, net weight and item category path.
  • Next steps: VP approve.

Approve item

AdMac will approve or reject all the action taken by other team members in the previous steps and can also modify the item code.

The legacy data needs to be validated, enriched, and modified by users followed by approvals from the VP. Then you need to load the data objects to Collaboration Area (intermediate process) from Catalog (check into Collaboration Area). Once validation is complete, enrichment and mediations are done and the item is saved in the FictXYZ Product catalog.  The collaboration area for this business process is Modify FictXYZ Product Collab Area.

To build the MDM Collaboration Server workflow, the collaboration area for Product Enrichment requires you to follow the design consideration along with properties and mandatory steps, is shown as follows.

  • User visibility step name: Approve.
  • Associated workflow: FictXYZ Product Enrich WF.
  • Container: FictXYZ Product Catalog.
  • Step type: General.
  • Participant's role (performers): VP Product Manager.
  • User drive to step: AdMac (VP who will approve the item after checking details, and he can also correct the item code if required).
  • Description: AdMac users have the privileges to approve the item in New FictXYZ Product Collab Area. This is the last step in the workflow.
  • Available exit choices:
    • APPROVED - The user will choose Success if all data is satisfactory.
    • REJECTED: The user will choose Fail if all data is not-satisfactory.
  • Editable attributes: Item code is editable, and the approver can change the Item code value if required.
  • Next steps: N/A.

Imports

FictXYZ Inc., has some legacy systems that are used to manage their food retail business. They want to transform business processes and technology capabilities to intelligently and efficiently respond to customers using Smarter IT systems.

Existing FictXYZ IT system uses ETL tools to extract data directly from legacy systems, and creates output as CSV files. Then the FictXYZ smarter merchandise system will develop processes in MDM Collaboration Server to accept and process data from CSV files and uploads it to the MDM Collaboration Server repository.

The FictXYZ smarter merchandise system project feeds the input data from the legacy source into the MDM Collaboration Server system. In the MDM Collaboration Server, the imports are first configured manually using MDM Collaboration Server UI and then are run on a scheduled or on-demand basis. Import will take legacy ETL output CSV files from a legacy end-point system.

Smarter merchandise systems need two imports to load the product category hierarchy and item data.

FictXYZ Product Hierarchy import

This import is responsible for loading the hierarchy data (food product categories and subcategories information). The details for this import in MDM Collaboration Server are shown as follows.

  • Feed name: FictXYZ Product Hierarchy import
  • ACG: Default
  • Feed target: FictXYZ Product Hierarchy
  • Feed type: Category (CTR)
  • Feed semantic: U (Update)
  • Data source: Browser upload
  • Character set: Cp1252
  • Incoming file format: CSV
  • Mapping of incoming fields: N/A
  • Sample file: Given below
  • Validations: No
  • Schedule: Scheduled
  • Error handling: If any row data is unable to update the Collaboration Server catalog, then update the audit log/FictXYZ hierarchy data_ddmmyy_hhmmss.txt file, which does not update successfully in the Collaboration Server system.
  • Error recovery process: Example - Import does not start: as this is a scheduled job, it will try to run the import for the next schedule.

Note: You can add more details in the table as per your requirements. For example, you can add Notification, Scripts Details, and so on.

Product hierarchy import implementation logic

This is considered as custom import which needs scripts to run in a scheduler job. Following are the standard steps that you need to write in the scripts to do the import.

  1. Get the input document (CSV file) into the buffer, read each row of the file, and then parse the row in CSV format. If the CSV file already contains a header, then skip the header row and continue.
  2. Take the level 1 (cat1) category code and create a new category object, update the code and description values of the fist level. Then get the level 2 category codes and create an object under the first category path, and map the data code and description until level 4.
  3. Repeat until you reach the end of the file.
  4. All category codes which are successfully updated in the Collaboration Server system need to also be updated in the Audit Log/FictXYZ Hierarchy data_ddmmyy_hhmmss.txt (in doc store) file saying that code was updated successfully.

FictXYZ Product Item Import

This import is responsible to load the food-product item data. The details for this import in MDM Collaboration Server are shown as follows.

  • Feed name: FictXYZ Product Item Import
  • ACG: Default
  • Feed target: FictXYZ Product Catalog
  • Feed type: Item (ITM)
  • Feed semantic: U (Update)
  • Data source: Browser upload
  • Character set: Cp1252
  • Incoming file format: CSV
  • Schedule: Scheduled
  • Error handling: If any row data is unable to update the  Collaboration Server hierarchy, then update the Audit Log/FictXYZ Product Item data_ddmmyy_hhmmss.txt file for the rows data that is not updated successfully in the Collaboration Server system, and then move to control for next line.
  • Error recovery process: Example - Import does not start: as this is a scheduled job, it will try to run the import for the next schedule.

Product items import implementation logic

This is considered as custom import which needs scripts to run in a scheduler job. Following are the standard steps to be written in the scripts to import.

  1. Get the input document (CSV file) into the buffer and read each row of file. Parse the row in CSV format if the CSV file contains header, then skip the header row and continue.
  2. Take the column 1 (primary key of the item) and check whether the item existed in FictXYZ Product Catalog. If it does not exist, then create the item object and update the primary key value, then update the remaining attributes (column1) data. Based on the SUBCLASS_CODE attribute value, map the item under that category in the FictXYZ Product Hierarchy.
  3. Repeat to end of the file.
  4. All the successfully updated items need to log in the Aduit Log/FictXYZ Product Item data_ddmmyy_hhmmss.txt file in DocStore.

Exports

FictXYZ smarter merchandise system develops a batch export to push data from the MDM Collaboration Server repository (which is populated by means of MDM Collaboration Server imports implementation details above) to a staging database from which it will get propagated to FictXYZ downstream systems.

FictXYZ downstream systems need a CSV file from MDM Collaboration Server system with the following attributes:

  • Item code
  • Item description
  • Item status
  • Expiry date
  • Vendor ID
  • Department code
  • Subclass code
  • Net weight
  • Warehouse code
  • Item nutrition ID
  • Item nutrition description

Smarter system implements one MDM Collaboration Server export (namely 'FictXYZ Product Ctg Export'), and this export is responsible to deliver the food-product item data from the MDM Collaboration Server repository. The details for this export in MDM Collaboration Server are shown as follows.

  • Export name: FictXYZ Product Ctg Export.
  • ACG: Default
  • Export dataset: FictXYZ Product Catalog
  • Export type: Product hierarchy of the catalog.
  • Export semantic: Incremental.
  • File delivery: Local environment.
  • Character set: Cp1252
  • Outgoing file format: CSV (simple comma separated).
  • Mapping of outgoing fields: Default map.
  • Volume of data: All.
  • Schedule: Hourly.
  • Notifications: If the export job fails, then a mail notification will be sent to the mail ID’s mentioned in the Export Configuration Catalog.
  • Error handling: Any error occurred, then send the notification email to authorized user.
  • Staging area: N/A.
  • Scripts: FictXYZ Ctg Export Script

Implementation logic

The proposed development strategy includes the following.

  • Create a catalog export in export console.
    1. In the catalog export script, you need to get each of the catalog item objects and each of the item attribute values into the declared variable.
    2. Write the attribute values into the FictXYZ Ctg Export_MM/dd/yyyy hh:mm:ss .CSV file with comma separated.
    3. If any error or exception occurs while getting the data into variables, or writing the data into the CSV file, you need to send the notification email to the provided list of user IDs.
    4. Output file formats: Item code, Item description, Item Status, Item nutrition ID, Item nutrition description, Vendor ID, Vendor Description, Net weight, Department Code, Expiry date, Subclass Code (Level 4 code of hierarchy code), Warehouse Code.”
  • Create export scripts using Java API.
    1. Class name: com.fictxyz.pim.ExportCatalog  // implements CatalogExportFucntion
    2. API used: com.ibm.pim.extentionpoints.CatalogExportFucntion
    3. com.ibm.pim.extensionpoints.CatalogFunctionArguments
    4. Method name: catalogExport
    5. Pointers: Use getItems method in CatalogExportFunctionArguments object to all the items related to the export.
    6. After creating your class, you need to copy it in /opt/pim/javaapiclass folder. This is so that you have deployed the class in the DocStore, which you can see in the DocStore console.
    7. This java class will be executed on the export job which executes the dataset into a CSV file in the Document Store.

Searching

The FictXYZ smarter merchandise system is focusing product centric master data to be searched quickly for making business process easier, faster, and managed. The search functionality mainly comprises finding food product, foods within the criteria (such as vegetable category) and product within a specific business unit (such as fresh food).  The MDM Collaboration Server UI facilitates searching these food-products information.

You have finished designing the FictXYZ smarter merchandise system for implementing it using IBM InfoSphere MDM Collaboration Server V10.0. The realization of this design is discussed in Part 2 of this article series.

You can start designing and implementing with your existing system to be enhanced in smarter merchandise IT system using IBM MDM Collaboration Server V10.0.


Conclusion

This article primarily shows you how to start designing and implementing a smarter merchandise system for a sample business case that falls under the MDM Collaboration Server platform, using IBM InfoSphere MDM Collaboration Server V10.0.

Every Section of each part of this series are elaborated so expediently, that technical readers can quickly get adopted and connected how to start with IBM MDM Collaboration Server based application design (Part 1 of this article series) followed by implementation in Part 2 of this article series.


Acknowledgement

The authors would like to thank the following people for their enormous contributions to the article:

  • Jeffery Alspaugh (alspaugh@us.ibm.com) - A senior IT specialist in IBM InfoSphere MDM Server for MDM Collaboration Server.
  • Sachin Prasad (sachin.prasad@in.ibm.com) - IBM InfoSphere MDM Collaboration Server Product Specialist - SWG.
  • Radha M Dey (radhamde@in.ibm.com) - A Senior IT specialist in J2EE Application Build, for his extensive review of this article.

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.
  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=824710
ArticleTitle=InfoSphere MDM Collaboration Server V10.0 design strategy and implementation, Part 1: A guideline using a sample business case
publish-date=09062012