Data Management Strategy
Formal architecture toward a common context for data to be viewed and managed as any other asset within the enterprise
MDM Repository Stucture
- Main table – One for each repository. In product repository, be the product including a field for each general valid piece of information
- Sub-tables – Lookup tables (value/customizing)
- Object tables – Images/text blocks and PDFs
- Special tables – Masks, families, image variants, relationships, roles, users, data groups
Main Table (flat table)
- A repository must only have one main table
- All other tables support it (directly-flat lookup or qualified lookup; / indirectly-tables linked to qualifier table & qualifier table linked to main T)
- Main table fields reference tables:
-- Flat lookup
-- Qualified lookup
-- Hierarchy
-- Taxonomy
-- Image, sound, video, PDF, and external binary object
-- Text block, copy blocks, and text HTML
-- Special tables
Flat & Qualified Lookup Table
- Flat tables (sub-table) can be multi-valued
- Qualified tables- Stores lookup records; Supports qualifiers; Is always multi-valued. Can be used for search
Hierarchy and Taxonomy Tables
- Hierarchy - sub-table orgainzing infor in a hierarchy (record related to parent/sibling record; contains lookup info for fields in main T; ordered sequence)
- Taxonomy- classification scheme that defines categories and subcategories.
Special Tables
- Families – Further partition records in taxonomy into smaller groups based upon values of other fields and/or attributes
- Relationships – Define different product-level relationships
Keep in mind...
- Many table and fields properties cannot be changed after creation (Table type; field type; multilingual option; Lookup table)
- Null values are not blank values
- Maintainable properties: (Name, code, Description, Display fields; Unique fields; Key mapping)
Repository Objects
- Taxonomies - general term classification scheme (hierarchy table, special lookup table) – created and managed using MDM Data Manager in Taxonomy mode.
- Attributes – characteristics in category (is a field applied to a subset of the records in a table)
- Product is assigned to category - Typical categorization of products is reflected in a taxonomy
- Flat / hierarchy lookup tables
- Taxonomy Lookup tables
- Qualified link tables – larger number of records
- Non-lookup sub-table = Relationship functionality (used for one-to-many relationship between main table records and sub table records
Relationship in Data Manager
- Parent/Child Relationship – Relates a group of records that are not equivalent (eg. Assembly)
- Sibling relationship – Relates a group of main table product records that are equivalent (eg. Cross sells)
Field Types & Properties
- Each table must have at least one Display Field (Display Field - value used as lookup field value; node name for the record; name of record in Product Relationships dialog box)
- Multiple Display Fields value is combination values separated by a comma
- Each field name must be unique within a table
- Items can be re-ordered
Field Details
- Variety of compond and structured data type (table types) specifically suited for managing info in a product repository
- Text Normalized – stores the actual text value, but uses normalized value for sorting and searching (upper-case with non-alphanumeric removed)
SOA for Business
•Open Standards
•Structure of a SOA Application – composed largely of services (Integration Services, Business Services, Data-Access Services)
•Web and Binary-Exchange Services – WSDL, SOAP, HTTP
•Presentation Services – Portlet, HTML,
•Runtime Products – security, service allocation, service composition, logging
•Loose Coupling
•Service Registry
•Service Level Agreements
Service Aspects
•Service Implementation - Logic
•Elementary access details – Location, binding, protocol, formatting
•Contract – interface and Quality of Service
Message Exchange Patterns
•One-way pattern – (fire-and-forget)
•Request-response pattern – (in-out)
•Notification pattern – (out-only)
•Solicit-response pattern – (out-in)
•Synchronous and Asynchronous Communication
•Callbacks – (Request and callback)
Quality of Service
•Reliability guarantees- availability, throughput, response time and probability, assured message
•Security mechanisms – Authentication, authorization, confidentiality, integrity, non-repudiation, attack protection
•Service coordination, including transaction control – Orchestration, Choreography
•Runtime update of address, binding, and message content – flow of traffic change, message reformat, send message to destination other than the requester
Process Steps
•Analyzing a Business Process
•Identifying Problems with current Process
•Communicating the Assumptions in Writing
•Isolating Services
•Creating the application
XML Schema
•Data Type – primitive, derived, simple, complex
•Purposes – data exchange, validation rules
•Groups, Sequencing,
SOA Standards
•WSDL
•SOAP
•UDDI
Introduction to BPEL
•BPEL process fulfills a workflow by accessing one service after another (partner service)
•BPEL activity is equivalent to a function call
•Running time can be far longer than other kinds of software
•Mechanisms for fault handling, compensation, correlation
•BPEL abstract process – subset of BPEL executable process (no implementation)
Additional language used by BPEL
•Query Language – XPath
•Expression language – XPath, Java
•doXslTransform
•Can use WSDL as source of data types
•PartnerLinkType (WSDL) – runtime conversation to partner service
BPEL Basics
•Activities– assign,compensate,compensateScope, empty, exit, extensionActivity, invoke, receive, reply, rethrow, throw, validate, wait
• An XML-base language for creating a process
•1. Accept a request for an insurance quote
•2. If the submitted details are appropriate, calculate the quote and include it in the response
•3. Otherwise, say "No" and include a justfication
BPEL - Partner Links
•Give details on the relationship between the BPEL process and each partner service
<partnerlinks>
<partnerlink name="ProcessQuote" partnerlinktype="ProcessQuotePLT" myrole="ProcessQuoteRole">
<partnerlink name="mainframeQuoteMgr" partnerrole="partnerRole" partnerlinktype="PartnerLinkPLT">
</partnerlinks>
BPEL - Variables
•assigns variables, which are memory areas that are each described by a Web Services Description Language (WSDL) message but could have been described by an XML Schema element or type
<variables>
<variable name="quoteRequest" messageType="placeQuoteRequestMsg" />
<variable name="highlightQuote" messageType="placeQuoteResponseMsg" />
<variable name="buildQuoteReq" messageType="buildQuoteRequestMsg" />
<variable name="newHighlightQuote" messageType="buildQuoteResponseMsg" />
</variables>
BPEL - Quote Request
receives a quote request
<receive name="processQuoteRequest" createInstance="yes" operation="placeQuote" partnerLink="ProcessQuote"
portType="ProcessQuote" variable="quoteRequest">
</receive>
BPEL - Copy Data
uses XPath syntax to copy data from the received message to a variable that is used for invoking another service
<assign name="AssignQuoteReq"> <copy>
<from variable="quoteRequest" part="placeQuoteParameters"> <query>/quoteInformation</query> </from>
<to variable="buildQuoteReq" part="buildQuoteParameters"> <query>/customerQuoteInfo</query></to>
</copy> </assign>
BPEL - Other Service
•invokes the other service, which calculates and returns a quote
<invoke name="CalculateQuote" inputVariable="buildQuoteReq" operation="buildQuote" outputVariable="newHighlightQuote" partnerLink="mainframeQuoteMgr" portType="QuoteManagement" />
BPEL - Copy to response
copies the quote details to another variable and in this way formats the response message
<assign name="AssignQuoteRes"> <copy>
<from variable="newHighlightQuote" part="buildQuoteResult"> <query>/quote</query> </from>
<to variable="highlightQuote" part="placeQuoteResult" > <query>/quote</query> </to>
</copy> </assign>
BPEL - Reply
•replies to the invoker, which may have been a Web application or a service
<reply name="processQuoteResponse" operation="placeQuote" partnerLink="ProcessQuote" portType="ProcessQuote" variable="highlightQuote" />
BPEL – General activities
•Run in a preset sequence
•Run in a loop
•Run on condition that a Boolean expression evaluates to true
•Run immediately or wait for some period of time, even years
•Run in response to an event that occurs after the process starts (specifically, in response to an inbound message, a calendar date and clock time, or the passing of time)
•Run in an order that differs for different instances of the same process
BPEL – Processes
•BPEL executable process – a Web service and acts as the hub in a service orchestration
•Software that runs an executable process is called a BPEL engine
•BPEL abstract process – similar to BPEL executable process but includes a subset of the information. It is a description of business logic, it omits implementation details in most cases
BPEL – WSDL
•PartnerLinkType – specifies the roles between the BPEL process and a partner service. (BPEL, WSDL)
•Port Type – WSDL
•Operations – WSDL
•Data types – XSD
BPEL – WSDL-based constructs
•Properties and property aliases benefits
•Use same name to access the same data in differently structured variables
•Name's position change doesn't necessarily change the logic in BPEL process
•BPEL correlation set (constants). Help direct an inbound message to the correct instance of BPEL process
BPEL – Process Elements
<process>
<import> </import>
<partnerLinks> </partnerLinks>
<messageExchanges> </messageExchanges>
<variables> </variables>
<correlationSets> </correlationSets>
<faultHandlers> </faultHandlers>
<eventHandlers> </eventHandlers>
<!— The previous two elements include activities, as does the subsequent content of the process element. Activities can be enclosed in scopes, as described later. —>
</process>
BPEL – File Structure
•Import - provides access to a WSDL definition or an XML Schema
•Partner link - is a kind of specialized variable that describes the relationship between the BPEL process and a partner service
•Message exchange - is an idnetifier that is used to avoid an ambiguous case in a complex usiness scenario – specifically, to pair a BPEL activity that receives a message with the activity that issues a reply
•Variable - contains business data (message, process logic)
•Correlation set – listing of properties used to correlate service instances
•Fault handler – a set of activities that run in response to a fault (failure in the process)
•Event handler – a set of activities that run concurrently with other activities, in response either to the passage of time or to receipt of a message
BPEL – Partner Link
•myRole – enacted by the BPEL process
•Operations are described in port type that is related to the role.
•partnerRole – enacted by the partner service
•Multiple partner links can be based on the same partner link type.
BPEL – Correlation Sets
•Maintain data integrity
•A list of propertirs whose values are expected to remain constant throughout a process or throughout a specific scope
•Reference only in activities that receive or transmit data
•Inbound activity – BPEL engine to direct msg
•Outbound activity – verify property values
•Inboundor outbound – initiates the correlation set
BPEL – Fault Handling
•Purpose – minimize the effect of an error
•Composed of a catch or optional catchAll
•Each fault handler hasselection criteria, which include (optionally) the fault name and the type of data
•BPEL engine selects the fault handler whose selection criteria most closely mirror the fault
•If the fault has a name but no data, BPEL engine selects the fault handler whose selection criteria match exactly
•If no catchAll, BPEL provides default:
<catchAll>
<sequence>
<compensate/>
<rethrow/>
</sequence>
</catchAll>
BPEL – Compensation Handling
•Compensation for a successfully completed scope occurs under the guidance of a compensation handler
•Invocation always comes from a parent scope
•The compensateScope activity invodes the compensation handler of a specific nested scope
•A failure in scope A causes invocation of the compensation handler in scope B:
<scope name="A">
<compensationHandler>
<compensateScope target="B">
</compensationHandler>
<scope name="B">
<compensationHandler>
<!— a basic or structured activity is here —>
</compensationHandler>
</scope>
</scope>
BPEL – Termination Handling
•Set of activities that are issues when a running scope is being forced to terminate
•Default
<terminationHandler >
<compensate/>
</terminationHandler>
BPEL - Concurrency
Synchronized - Activities run concurrently and one activity is forced to wait for another
BPEL Activity – Start
•First activity (other than flow, scope or sequence)
•1. a receive activity
•2. a pick activity that contains only onMessage events
