Support for SAP NetWeaver 7.30 has been qualified for the following MDM components:
● MDM Web Dynpro Components
● MDM Portal iViews
● MDM Portal Content (Product and Business Partners)
● MDM Web Services (design time and runtime)
● MDM Enrichment Controller
● MDM PI Adapter
● MDM Java API
● MDM ABAP API
● Collaborative Processes for Material Master Data Creation
For more information, see the SAP NetWeaver MDM 7.1 Master Guide on SAP Service Marketplace at http://service.sap.com/installmdm71.
A traditional SQL DBMS stores data in the records and fields (rows and columns) of a collection of flat database tables. All tables have the same rectangular structure in SQL. A SQL database is relational because of the relationships set up between the different tables.
In an relational DBMS (RDBMS), information about a single record can be combined from multiple tables by relating values in matching columns. This helps to eliminate redundant data; beyond that, however, an RDBMS does not support any additional structuring of the data itself.
By contrast, the MDM system supports a variety of different table types that are specifically suited for the particular requirements of storing, organizing, structuring, classifying, managing, and publishing information in an MDM repository (including efficient support for category-specific attributes, which are inherently non-relational), as shown in the following table.
Table Type
Description
Main table and subtables
Flat
Main table or subtable. A flat table has the standard, rectangular SQL structure consisting of records and fields (rows and columns). The main table of an MDM repository is always a flat table.
Hierarchy
Subtable. A hierarchy table organizes information in a hierarchy, where each record is related to a parent record (even if the only parent is the root) and may also be related to sibling records and/or child records. The main table in an MDM repository typically contains some fields whose data may be hierarchical in nature. For example, a Manufacturer field may need to accommodate division and subdivision information for manufacturers. This hierarchical information is stored in a separate, hierarchy subtable associated with the Manufacturer lookup field in the main table. Most of the hierarchy tables used in an MDM repository contain lookup information for fields in the main table. Other hierarchy tables in MDM include taxonomy tables, the Masks table, and the Families table, described below. MDM supports hierarchies with an unlimited number of parent/child levels.
Note that a hierarchy table is useful even when it is flat (i.e. only leaf nodes below the root), because it stores the ordered sequence of sibling records, allowing you to override the unordered sequence of values in a flat table and instead put the values in a fixed order.
Taxonomy
Subtable. A taxonomy is the classification scheme that defines the categories and subcategories that apply to a collection of records. Categorizing records enables you to isolate subsets of records for various organizing, searching, editing and publishing purposes.
A taxonomy table in MDM stores a hierarchy of categories and subcategories and also supports attributes, “subfields” that apply to particular categories rather than to the entire collection of records. MDM supports multiple simultaneous taxonomies.
Qualified
Subtable. A qualified table in MDM stores a set of lookup records, and also supports qualifiers, “subfields” that apply not to the qualified table record by itself, but rather to each association of a qualified table record with a main table record. MDM supports multiple simultaneous qualified tables.
Qualified tables can be used to support product applications and application-based search, and also to store any large set of subtable records that contain fields whose values are different for each main table record, such as multiple prices for different quantities, divisions, regions, or trading partners, cross-reference part numbers, and additional distributor/supplier/customer-specific information for different distributors, suppliers, or customers.
Object tables
Images
A single table named Images. Stores image files, where each image is stored as a record in the table.
Text Blocks
A single table named Text Blocks. Stores blocks of text, where each text block is stored as a record in the table.
Copy Blocks
A single table named Copy Blocks. Stores blocks of text interpreted as copy, where each text block is stored as a record in the table.
Text HTMLs
A single table named Text HTMLs. Stores blocks of text interpreted as HTML, where each text block is stored as a record in the table.
PDFs
A single table named PDFs. Stores PDF files, where each PDF is stored as a record in the table.
Sounds
A single table named Sounds. Stores sound files, where each sound file is stored as a record in the table.
Videos
A single table named Videos. Stores video files, where each video file is stored as a record in the table.
Binary Objects
A single table named Binary Objects. Stores other binary object files, where each binary object file is stored as a record in the table.
Special tables
Masks
A single hierarchy table named Masks. In concept, a mask acts like a stencil, in that it blocks (“masks”) all main table records from view except the defined subset of records that are included in the mask, to allow the subset to be viewed and manipulated as a whole. A mask is a static snapshot of the set of records that are included in the mask (as opposed to a view or a named search, where the results set is determined dynamically every time the search is run). Each record in the Masks table is the name of a subset of main table records. MDM supports an unlimited hierarchy of masks.
Named Searches
A single flat table named Named Searches. A named search is a static snapshot of the search selections that were in effect when the named search was saved (as opposed to a mask, which is a snapshot of the subset of records), where the results set itself is determined dynamically when it is selected. Each record in the Named Searches table returns a subset of main table records. MDM supports 400 named searches per repository.
Families
A single hierarchy table named Families. Used to further partition main table records in each category into smaller groups based upon the values of other fields and/or attributes. You can associate family data (a paragraph, an image, bullets) once with a family of products rather than with each individual product, and also define the table layout of the field and/or attribute data (field order; stack, vertical, and horizontal pivots; and other display options). This table is available only in Family mode.
Image Variants
(Does not appear anywhere in the MDM Client)
A single table named Image Variants. Used to define the structure and format of each of the variants for each image. Each variant is a modified version derived from an original image; the original image is never modified. This table is managed in the MDM Console and is not visible in the MDM Client.
Relationships
(Does not appear anywhere in the MDM Client)
A single table named Relationships. Used to define each of the different record-level relationships. Each relationship can be either bidirectional (sibling) or unidirectional (parent-child). This table is managed in the MDM Console and is not visible in the MDM Client, although the relationships between records can themselves be created and edited in Record mode.
Workflows
A single table named Workflows. Stores the workflows of an MDM repository, where each workflow is stored as a record in the table. Workflows are created and edited in the MDM Client.
Data Groups
A single hierarchy table named Data Groups. Stores the hierarchy of data groups used to break the entire set of objects in the MDM repository into manageable subgroups.
Validation Groups
A single hierarchy table named Validation Groups. Stores the hierarchy of validation groups used to organize multiple validations for subsequent execution as a group.
System tables
Roles
(Does not appear anywhere in the MDM Client)
A single table named Roles. One of three tables used to implement MDM repository security and access control. Each role can selectively grant or deny access to any MDM function and to any table or field. This table is managed in the MDM Console.
Users
(Does not appear anywhere in the MDM Client)
A single table named Users. One of three tables used to implement MDM repository security and access control. Each user can have one or more roles. This table is managed in the MDM Console.
Logins
(Does not appear anywhere in the MDM Client)
A single table named Logins. One of three tables used to implement MDM repository security and access control. Contains an entry for each currently connected MDM client application, which can be terminated by the MDM Console user.
Change Tracking
(Does not appear anywhere in the MDM Client)
A single table named Change Tracking. Allows you to specify the fields for which adds, modifies, and deletes should be tracked and stored in the Change Tracking table.
Remote Systems
(Does not appear anywhere in the MDM Client)
A single table named Remote Systems. Used to define the different remote systems for import and export. Each remote system specifies whether it supports import only, export only, or both.
Ports
(Does not appear anywhere in the MDM Client)
A single table named Ports. Used to encapsulate the logistical and configuration info for inbound and outbound processing of MDM data, for consolidation and distribution respectively.
URLs
(Does not appear anywhere in the MDM Client)
A single table named URLs. Used to specify the URLs that can be used as the target of an embedded browser in the Web tab in the MDM Client.
XML Schemas
(Does not appear anywhere in the MDM Client)
A single table named XML Schemas. Used to identify the XML schemas for import and syndication. Each XML schema is the name of an .xsd file.
Reports
(Does not appear anywhere in the MDM Client)
A single table named Reports. Contains an entry for each report file generated by the various MDM repository operations, which can be accessed and viewed by the MDM Console user.
Logs
(Does not appear anywhere in the MDM Client)
A single table named Logs. Contains an entry for the log files generated by the MDM Server, which can be accessed and viewed by the MDM Console user.
An MDM repository consists of the following tables:
Main table
Every MDM repository has exactly one main table. The main table consists of the primary information about each main table record. For example, an MDM repository of product information would include an individual record for each product and an individual field for each piece of information that applies to all products, such as SKU, product name, product description, manufacturer, and price. Most of the time you will be looking at information in the main table.
Subtables
An MDM repository can have any number of subtables. A subtable is usually used as a lookup table to define the set of legal values to which a corresponding lookup field in the main table can be assigned; these tables hold the lookup information. For example, the main table of an MDM repository of product information may include a field called Manufacturer; the actual list of allowed manufacturer names would be contained in a subtable. Only values that exist in records of the subtable can be assigned to the value of the corresponding lookup field in the main table.
Lookup subtables are just one of the powerful ways that MDM enforces data integrity in an MDM repository. The set of legal values associated with lookup fields also makes the MDM repository much more searchable, since a consistent set of values is used across the entire repository.
Object tables
Object tables include the Images, Text Blocks, Copy Blocks, Text HTMLs, and PDFs tables. An object table is a special type of lookup subtable, where each object table is used to store a single type of object, such as images, text blocks, copy blocks, HTML text blocks, or PDF files. You cannot store an object directly in a main or subtable field in an MDM repository. Instead, each object is defined or imported into the repository once and then linked to a main or subtable field as a lookup into the object table of that type.
Object tables eliminate redundant information, since each object appears only once in the MDM repository even if it is linked to multiple records.
Special tables
Special tables include the Masks, Families, Image Variants, Relationships, Workflows, Data Groups, and Validation Groups tables.
System tables
System tables appear under the Admin node in the Console Hierarchy and include the Roles, Users, Logins, Change Tracking, Remote Systems, XML Schemas, Reports, and Logs tables.
SAP MDM Tutorials | SAP MDM Training | SAP MDM Interview Questions |SAP MDM Books
The MDM Client operates in five modes. Each mode is designed for manipulating specific types of tables and repository information, as follows:
Record mode
Allows you to search, view and edit the records of any table in the MDM repository. This is the mode you will use most often, primarily to view and edit records in the main table, but also to view and edit records in any of the subtables.
Hierarchy mode
Allows you to view and edit the hierarchy tables in the MDM repository, including regular hierarchy tables, taxonomy tables, and the Masks table. Though you can also view and edit the records of a hierarchy table in Record mode, Hierarchy mode specifically allows you to edit the parent/child relationships and the sibling ordering of the hierarchy.
Taxonomy mode
Allows you to view and edit the taxonomy tables in the MDM repository. You will use this mode to create and maintain the category hierarchy used in the repository, and to manage the attributes associated with each category and subcategory. Though you can also view and edit taxonomy tables in both Record mode (for searching) and Hierarchy mode (for editing the other fields of information associated with each category), Taxonomy mode is unique in that instead of focusing on the records of the taxonomy table, it allows you to create and manage the pool of attributes associated with the taxonomy table, and to assign attributes to categories on a category-by-category basis.
Matching mode
Allows you to identify and eliminate duplicate records within an MDM repository. When you view the main table in Matching mode, MDM allows you to perform “matching-and-merging” on and against any or all of its records, using various user-defined criteria to decide whether or not records are potential duplicates.
Familiy mode
Allows you to view and edit the Families table, which layers a hierarchy of families upon the taxonomy hierarchy to further break down each category into smaller groups of main table records. Use this mode to partition the categories of the taxonomy hierarchy by the values of other fields and/or attributes, and then to associate family data (such as an image, a paragraph, and bullets) once with each family of main table records rather than each individual record.
· Select a message and press Display.
You may notice that I have selected a message that coantains an error and did not actually reach it's destination. In Call Adapter -> SOAP Header take a look at Error. If you double click that button a screen will appear on the right hand side that shows the details of the error. 
This error tells us that something is wrong with the IDoc Adapter. It tells us that transaction IDX1 contains errors, but in this case the error is actually in the configuration of our communication channel, in which we have made reference to the wrong Port. If you select Call Adapter -> Payloads you can see the content of the XML message that came from MDM. 
If you go back to SXMB_MONI you may want to also take a look at the Processing Statistics program that will show a good overview which can be helpful when testing your interface with thousands of materials.
3. Testing
Now we're going to go ahead and test out the interface from end to end. I'm assuming that by now you have turned on the MDM Syndication Server and your XI interface is activated in the Integration Directory. Lets log into the MDM Data Manager and create a new material for testing purposes.
· Right click -> Add
· Enter enough data to satisfy your interface requirements (ie: which fields must be populated?)
· Click on another material to save changes
· Close the MDM Data Manager
· Turn on your MDM Syndication Server (if it's not already turned on)
If your Syndication Server settings have been configured correctly then we can assume that because you added a new material to the data manager, it will now syndicate as soon as your interval cycles through (set in the mdss.ini file on your server). Lets go ahead and move over to the Exchange Infrastructure Runtime Workbench to see if it has processed our message. Keep in mind, depending on your interval time it may take a few minutes. Hopefully you should see something like this: 
If the runtime workbench shows the message transferred successfully then lets log ino ECC and see if the IDoc was posted.
· Log into ECC system
· Run transaction WE02
· Press F8
· In the left hand pane, select Inbound IDocs -> MATMAS
· In the right hand pane, select the IDoc that just transferred and double click on it
· In the IDoc display, on the left hand side expand E1MARAM and select E1MAKTM
· Verify that the material data is correct
· Expand Status Records -> 53 and double click the only record available
· In the pop up window, copy the message number that was issued to the IDoc
· Press Proceed
· Paste the message number that you copied
· Press F8
You may notice that my image says material 11696 created. This is because a modification was made to an ABAP program to create a material when an IDoc is processed with a certain code. In this blog, the ABAP modification is out of scope, but I'm assuming if you are familiar with ALE then this process should be familiar as well. In any case, this is not a permanent solution, just a temporary solution to finish our prototype. If we take that newly generated material number and run transaction MM02 we should be able to pull up the details on that material. 
Press Select Views and select Basic Data and continue. 
Hopefully if all went as planned, the material should have transferred smoothly, with no loss in data. This concludes the three part series on MDM and XI. Thanks for reading, hopefully it helps!
2. Exchange Infrastructure
Now we'll take a look at the second half of this scenario and test out our XI interface.
2.1 Check Configuration
The only configuration we are going to check is the outbound communication channel. This is what tells Exchange Infrastructure where to pick up what file (location, filename) and do what after it's processed by the inbound communication channel (processing mode, ie: delete).
· Start your Integration Directory (Integration Builder: Configuration).
· Navigate to your outbound communication channel.
· Examine your File Access Parameters.
In my case, because this is a test scenario, I have a bash script picking up the file from the port directory and dropping it onto a drive that all of the SAP systems have access to; this being the /depot filesystem. As you can see I made a temporary folder on that filesystem for the files for this interface to be stored while waiting to be processed. Of course, the simplest way to do this would be to mount the Port directory from your MDM machine to your XI machine. Next take a look at your Processing Parameters and change the settings accordingly. For this particular scenario I have set the poll interval to 5 seconds for testing purposes. Also, notice that I am using delete as the processing parameter. This is so that I can verify that the file was processed, and so the folder doesn't get cluttered up with files. 
If everything is the way you want it, lets go ahead and take a look at some important locations that will come in handy for testing and debugging the interface.
2.2 Important Locations
2.2.1 Integration Repository - Map Testing
Start the Integration Repository (Integration Builder: Design) and navigate to the map that we built in Part II. Select the Test tab. 
To test our map, we can actually use the XML document that MDM generated via the Syndication Server. Lets go ahead and try this.
· Press the "Load Test Instance" button.
· Select the XML file MDM generated.
· Press the "Start Transformation" button.
If everything went smooth then you should see a pop up screen that says "Executed successfully". Otherwise you will recieve an error to which you can begin your debugging process.
2.2.2 Runtime Workbench - Component Monitoring
The runtime workbench is one of the most powerful and useful features of Exchange Infrastructure. Here we can get very detailed descriptions of errors that may occur with each component of XI. The component that we will want to pay particular attention to is the Adapter Engine.
· Log into your runtime workbench and select Component Monitoring -> Display.
· Click the Adapter Engine link.
Here you can view the status of the adapter. If there is an error in your configuration of a particular adapter it will show up here.
2.2.3 Runtime Workbench - Message Monitoring
Follow a similar procedure to display that Message Monitoring.
· Select your time filter, in this case I will select the last hour.
· Press Start.
You can now see the list of messages that have been processed by the Adapter Engine over the last hour. On my system only one message has been processed in the last hour. You can press either Details or Versions to view more information about any particular message that was processed.
2.2.4 Integration Engine - Monitoring
This is a particularly useful component of Exchange Infrastructure that allows us to view various aspects of the messages that get processed. Lets start by logging into the XI system and taking a look.
· Run transaction SXMB_MONI.
· Double-click Monitor for Processed XML Messages.
· Press F8 or the Execute button.
Hello and welcome back to the last of a three part series on integrating MDM with ECC with XI (sorry for the onslaught of acronyms). If you missed out on the first two you can find them here: Part I, Part II. In this one we will focus on testing out your scenario, and how to troubleshoot (where to look) in both MDM and XI. You may have already noticed that in the previous two parts of this series I used a sample scenario dealing with material master data and the MATMAS05 IDoc structure. Ultimately we want to generate a new material in ECC based on the creation of a material in MDM.So lets go ahead and get started. First we'll start with the syndication process in MDM, and making sure our settings are correct.
1. MDM
First we'll start with the syndication process in MDM, and making sure our settings are correct.
1.1 Check Configuration
1.1.1 Client-Side Settings
· Open the MDM Console
· Navigate to Ports in the repository to which your map is located.
· Verify that you have selected the correct map (built in Part I)
· Select your processing mode as Automatic
· Open the MDM Syndicator (Select the repository and press OK)
· Select File->Open
· Select the remote system representing ECC
· Select your map and press OK
· Select the Map Properties tab
· Check Suppress Unchanged Records so we automatically update only changed records.
· Close and save your map
1.1.2 Server-Side Settings
· Open your mdss.ini file on the MDM server
· Verify that Auto Syndication Task Enabled=True
· For testing purposes, change the Auto Syndication Task Delay (seconds) to something rather small, such as 30 or less. This way you don't have to wait a long time for syndication when testing.
· Verify that the service is started.
· UNIX systems: ps -ef | grep mdss
· WINDOWS systems: open services, and look for entry regarding syndication server
· If service is not running, run command ./mdss (UNIX) or rightclick->start service (WINDOWS)
1.2 Important Locations
I'd like to go over some of the important locations (directories) on your server that will come in handy when troubleshooting and testing. One of the trickiest parts of working with MDM is figuring out where things go and where to look. Because it's so different from the SAP software that we are all used to, navigating the system is not as easy as running a transaction code. Also, MDM reacts to certain situations differently that you may expect, so it's important to know where to look when things aren't working properly. I'm working with MDM installed on HP-UX, however I will try to address each topic as it would appear in Windows to the best of my knowledge.
1.2.1 Home
Log onto your MDM server and navigate to the home directory for the MDM application server. On the server I am working with (sandbox) it happens to be located on the opt filesystem, and the path looks like /opt/MDM. In this directory take note of several important directories:
/opt/MDM/Distributions
/opt/MDM/Logs
/opt/MDM/bin
The Distributions folder is very important because this is where the port directories get created. When you create a port in the MDM Console for a particular repository, it creates a subset of folders in the Distributions directory based on which repository the port was created in, and whether the port is inbound or outbound. For example, in our particular scenario we may navigate to the path/opt/MDM/Distributions/install_specific_directory/Material/Outbound/. Here we will notice a folder entitled ECC which (if you followed the fist part of this series) corresponds to the port that we created earlier. This directory was created as soon as the port was created in the MDM Console. We will focus more on the contents of our port directory shortly.
The Logs folder contains several important log files, however most of them will not apply to our particular scenario, because the logs that we will want to look at are going to be specific to the syndication process, and are located within the port directory. Neverless, I thought it was important to mention that in certain troubleshooting scenarios, don't forget that these log files also exist.
The Bin directory is critical because that is where the files that start the app servers are located. The programs mds, mdss, and mdis are critical files.
1.2.2 Port
Your port directory is going to have the following format:
/MDM_HOME_DIRECTORY/Distributions/MDM_NAME/REPOSITORY/Outbound/REMOTE_SYSTEM/CODE/
For example the we created looks like this:
/opt/MDM/SID.WORLD_ORCL/Material/Outbound/ECC/Out_ECC/
Here you should see the following directories:
/Archive
/Exception
/Log
/Ready
/Status
The Archive directory is not as important during the process of syndication as it is with the process of importing data into MDM. This directory contains the processed data. For example, if you were to import an XML document containing material master data, a message would get placed in the archive directory for reference later if you ever needed to check.
The Exception directory is very important because often times when an error occurs you can find a file has been generated in the Exceptions folder that should look similar to that file that either the import server or the syndication server are attempting to import or syndicate. In other words, lets say you were attempting to import an XML document that contained material master data, but the map that was built in MDM has a logic error, the document will instead get passed to the Exceptions folder and the status of the port will be changed in the MDM Console program to "blocked".
The Log directory is important for the obvious reason. Logs are created each time the syndication server runs. So if your interval is 30 seconds, then a log will be generated in this folder every 30 seconds. It will give you the details of the syndication process which ultimately can be critical in the troubleshooting process.
The Ready folder is the most important folder in our scenario. When the Syndication Server polls during it's interval and performs the syndication, the generated XML message will appear in the Ready folder. So in the case of our scenario, we are going to have material master data exported to this directory and ultimately Exchange Infraustructure is going to pick up the data and process it to ECC.
The Status directory contains XML files that hold certain information pertaining to the import / export of data. This information includes processing codes and timestamps.
1.3 Testing
Now are going to test out our scenario and make sure that the export of materials works correctly. First things first, we need to create a new material in the MDM Data Manager. Make sure that your MDM syndication server is turned on! Remember on UNIX we can start it by running ./mdss in the /bindirectory, and on Windows by simply starting the service.
1.3.1 MDM Data Manager
· Start MDM Data Manager
· Connect to Material repository.
· Add a new material by "right-click".
· Fill in required fields to satisfy the map built in Part I.
· Verify the new product is saved by clicking elsewhere in the Records screen, and then back to the new Material.
1.3.2 Check Syndication
We are now going go verify that the syndication process is taking place as it should based on the settings in your mdss.ini file. If you have set the MDM Syndication Server to perform the syndication process every 30 seconds, as I set it for testing purposes, then by the time you log into your server the syndication should have already occured. Lets check by logging onto the server and navigating to the Ready folder in our Port directory.
/opt/MDMSID.WORLD_ORCL/Material/Outbound/ECC/Out_ECC/
If all went as planned your Ready folder may look something like this: 
Those files are XML files that contain the data for each material in your repository that has changed. In this case the only materials in my repository are the two that I just added, so the MDM Syndication Server updated the Ready folder with both new materials. Now they are waiting for XI to pick them up and process them. Before we move over to the XI part lets take a look at one of these files and verify that the data in them is correct. Keep in mind that if you have already configured XI to pick up the files from this directory and process them, it's possible you won't see them here because they have already been deleted by XI (based on the settings in your communication channel).
1.3.3 Verify Data
Lets go ahead and open one of these files. I copied the file from the server to my local Windows running computer to examine the file, but of course you can read the file straight from the server if you prefer. If your mapping was done similar to mine, your file should look like a MATMAS05 IDoc in XML structure. This is to make it easier for XI to process since we can export in this format from MDM without much difficulty.
Common CLIX errors are listed in Table 112.
Table 112. Common CLIX Errors
388
MDM Console ![clip_image010[7]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizOlJZ8k9NXmsM3wElWsSHKRYvGy_oD4mB1ARH7fAiy4STBjOTgll0n1m6eMya6nYG-gug62eG6-UNHqwHyJcbHlpjiAfQHNOAGtAO1QR-zMu8cUp3BLH-fSN0I-WpSwe9A8MdTTYPjoE/s1600-h/clip_image010%5B7%5D%5B2%5D.gif "clip_image010[7]"){kind=small}
|
DBMS Settings
DBMS Settings
The applicable brands for each DBMS setting are listed in Table 113.
Table 113. DBMS Settings and Brands
NOTE ►► See “DBMS Settings” on page 234 for more information on
the DBMS settings.
![clip_image004[1]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhSvynU1GTn8_-jK96ug4BYxvp4iuiAStcYdw0OcMkZ3u9qjzuT27FTYg1ljjxHt2tFFikbyNXgZVlt6Oe5doCrEoSyMZfJJCoZ1K-kDgptnEHAGGF_pe50vaBcpGRPRG8HXp1Ufx6R6g8/s1600-h/clip_image004%5B1%5D%5B2%5D.gif "clip_image004[1]"){kind=small}
![clip_image008[1]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1PuxPclco1_IhZKp-PyqwSWMqMtyUuh4gFdKQGSYaBWHLuu2kYsMmfGILBZBwqC5uzQXvxp5yDS0Z9vN0ynZjQJi5LTKZBtO_QsjedhmRldt4BECBxbaXYSRJP3g9kDUqz3rY0LIj__I/s1600-h/clip_image008%5B1%5D%5B2%5D.gif "clip_image008[1]"){kind=small}
![clip_image010[1]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZv65oZeY0PM5TDQOzmfr-64vFVFySnwp1k8UJP-A7lmMkoWV_NFMXmXklUTcvHXxGDBBhYFmHbbvgBTDN15hEMKW97hqre08jYL4OYjYqUtglaVzM1gnMGn1TMLUXIL9C_uNTZ-SdmBo/s1600-h/clip_image010%5B1%5D%5B2%5D.gif "clip_image010[1]"){kind=small}
![clip_image010[2]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4F6LEcL6IfYCgMREKBeKMrvVib8VUaQoUmEOgr85gaiaoiA8BlJoQ6SrQukfQ0z0aNO0bL5gomkhydl6l4sGHiT1NVpkG9crGc6JoAd_TngzmP-0KQNT6bVfYaLbd76e7aVz3myOEuYw/s1600-h/clip_image010%5B2%5D%5B2%5D.gif "clip_image010[2]"){kind=small}
![clip_image010[3]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsWaH9UF5TMvlQQn1Z8PhM-MTBUUU1p33IEthwpAIrcXs27h011aWd173Ei100QkKNGKMO0rNk6vSIJK-Wf1836TCS9zUlBAmZzGLLEX1a9H8MkljTKQnsvCOIo6K1Lxu4JUgjigNUonU/s1600-h/clip_image010%5B3%5D%5B2%5D.gif "clip_image010[3]"){kind=small}
![clip_image004[2]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjt8tAvKyQyekc23fTeNdt8bsoa5GyBlDMyxlLcAJ2zjJNhba-F9G9LQA2tXL6aqDgGN8CK_M74X5J-4Cu5DkbZOAQplYjZvNSsJ_9gWxN9qCBPxPza6tPqIG8Vxq2vGElkIcKikmoz8fs/s1600-h/clip_image004%5B2%5D%5B2%5D.gif "clip_image004[2]"){kind=small}
![clip_image004[3]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEin3vGgJH0B0vNRuM4H5hxUM1M8v7N_G22eCavmivIycVqNKYmhnqyRE5s6YHexCoDEV6Gf5AYy76tbg6gatLsV4u-aWnHfBAdbB5LSsW3XLYAV9BS0CsDNEQZAUQrAw2KoUzZ9Vhw4FWM/s1600-h/clip_image004%5B3%5D%5B2%5D.gif "clip_image004[3]"){kind=small}
![clip_image006[1]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbfpT0srngIjQvNmwNCE_oGNm4jUhOGv9qM94Sr3sFsdGXgbvKDFComvsIrU7VGwILqLiBH0_bR4JCjMV5MihIiILaWgrbG2YNsyrOirER9zLs_xQk5StizvKbc3pFSIYoLmZh1furYQ4/s1600-h/clip_image006%5B1%5D%5B2%5D.gif "clip_image006[1]"){kind=small}
![clip_image008[2]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmXMd6_FYjbt_sGdJbGbUjpMjiLbkzx1pJaA9a5e4BA5ezdTb-EXtT9QKA0KFp_CU4HRNqfgwPBewJbiMm1ViiX0O-htpvoEMwEaN2FhBHzu6_5L884H1ZpOUYMNlnwYd8PKdw_frrXZI/s1600-h/clip_image008%5B2%5D%5B2%5D.gif "clip_image008[2]"){kind=small}
![clip_image008[3]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTCBdIz2RFBS80RGkQfusjICqiv8ZDhHy7uqpNyxVutiXKInScl2OvSfepo019-dhyphenhyphen5wQRFqeKh-wAEql6C35cei-__YrEq7qC4pgslxinYOmh3eR0aJCs-nhmsSEfbEe_1H6hzSQ5o58/s1600-h/clip_image008%5B3%5D%5B2%5D.gif "clip_image008[3]"){kind=small}
![clip_image010[4]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi11KfcVnGMkxtAwjRHj2ra0Ko8bWYotXWwNblnY3JjNuNmOEohHMvF3XDGuRIO8yfGzOvNgWpXaE79juZTS3CpMGiV89-bWlyfVkq80cAIa_Ku2TkIzEwfYpTUT4OMvvl_a1lKCF49ctY/s1600-h/clip_image010%5B4%5D%5B2%5D.gif "clip_image010[4]"){kind=small}
![clip_image010[5]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQUc6MEK-In3VFGRsrO2D1UNlYmQs9cRuLwF6mjh2GDa4WSRh3J83cD81TSryO84o42Kdb2UTAllKMLlf6NVt0ew0mzYZn_hSuAHlSeEiOLr6YE2rx1o_Vi_est2LwwNEVmhnf8ZPkwAk/s1600-h/clip_image010%5B5%5D%5B2%5D.gif "clip_image010[5]"){kind=small}
![clip_image010[6]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5rGxhcBGsm80f4NJuh-clexJQkKQLLYFQGM0Zf1rFBVAHmVSLq92Jc1v4C9lhTyt1U5G4fAf4paSW69bdA2p8TGjBvFTQv241uWCqT__h-mHs57B-ke4J_kXU24Icer7vWaEEGGndbug/s1600-h/clip_image010%5B6%5D%5B2%5D.gif "clip_image010[6]"){kind=small}