Skip to Content

Problem Statement

Many of us use the Manufacturing Data Objects in MII to create data stores (DB tables) because of the ease of use and also the host of functionalities that are available for MDOs but not in DB tables directly created in the database. Some of these are ability to load data into the MDO using lifecycle jobs, no need to map fields from source to target, OpenSQL support and not have to worry about the underlying database. For more details on why you should use MDO or when please read this wonderful blog by Salvatore Castro http://scn.sap.com/community/manufacturing/mii/blog/2014/01/14/sap-java-data-dictionary-sap-mii-mdo.

However the main issue a lot of us complain about is that the data in MDO cannot be exported/imported like we can do with objects in Workbench or with configurations. This may be necessary for transporting data from Quality MII system to Production for configuration or master data stored in MDOs.

The main reason why this is not possible/difficult to provide out of the box is that MII system has no knowledge of the amount of data stored in the MDO and it might be very difficult to export such data and import them.

Lets see how we can achieve this without much problem.

Steps for transporting MDO Data from source MII to target MII

1. Create an MDO in the Source System. For simplicity sake I created a very skinny MDO with only 2 fields Key and Value

1.PNG

2. Inserted a few records in this MDO

3. Exported this MDO and imported in my target MII server.

4. In my source MII system I created a Virtual MDO Data Server pointing to my target system

2.PNG

5. Create an MDO Query using the Virtual Connector created in step 4 with Insert mode.

Note that if you create the Virtual in Target MII System pointing to source your query should be of select mode.

6. Create a Select query in source MII system to read the data from the local MDO.

7. Create a transaction. Inside the first step is to call the select query in Step 6. Next we put a Repeater to repeat on the rows. Finally we map the individual records to the Insert query in Step 5 and insert them in the remote MDO.

8. Execute the Transaction and my data is transported.

Another Approach

The above is a very basic way of transporting data and mostly works for one time loads. What if you need to periodically load data from one MII system to another?

I would then do the following

1. Create/Import MDO definition from source system into target system

2. Create a virtual connector in target system pointing to the source system

3. Create an MDO query with select mode to read data from the MDO in source system. Choose the Data Server in the query as the one created in Step 2. Ensure to select all fields except the LASTTASKEXECUTION, LASTTASKEXECUTIONBY, LASTQUERYEXECUTION, LASTQUERYEXECUTIONBY fields.

4. Open the imported MDO and go to its Data Provider screen and select the query created in step 3.

5. In the Attributes screen map the data provider columns to the MDO columns. Alternately you may just create a new MDO and copy all the fields of the query into this. In this way you can skip the import process as well. However ensure the MDO is named the same if it is used in other objects.

6. Go to Lifecycle screen of the MDO and create a new job with either Update or Replace mode to fill data into the MDO. Set a frequency as per your needs. Deploy the job and run it.

7. Execute the MDO to see if the data is available in the MDO.

This approach will keep your target MII always updated with data from source.

Points to Note

1. The second approach runs automatic and keeps data updated. However if you want to control when and what data is sent to target you will need to use the first approach and not the second.

2. First approach might result in Primary Key violations in case you make a mistake. Second case such chances are not there.

Hope this helps you with transporting MDO data. You may also use this for DB tables that are not MDOs. Please let me know your thoughts.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply