Regarding MDO

[Former Member]

Hi,

As SAP Help says "An MDO is a semantic layer and level of abstraction on top of SAP Manufacturing Integration and Intelligence (SAP MII) data acquisition mechanisms". I understand that the concept of MDO is to provide a data interaction layer between the User Interface and the Data sources. It is definitely useful for developing a product for multi plant deployment because the data interaction layer(MDO) works same even though the data sources changes from plan to plant.

Question 1: Would you please let me know my understanding is correct or wrong?

In several implementation we use the SQL DB layer to persist the transaction data or keep the master data to validate before we pass it to ERP.

Eg. MES can do the confirmation of a production order but before User does a goods movement during confirmation it should provide a valid Storage location to the Level 4 systems (SAP ECC or BAAN). To do this kind of validation MES also keeps a set of master data at MES layer.

For a similar scenario in MII we keep the Master data in SQL DB connected to MII.

Question 2: As we have Persistent MDO, do we design the application such a way that the transaction data and master data resides in MDO? I am assuming that we are not doing any more data base design in SQL to create the application, we are totally dependent on Persistent MDO.

Waiting for all the suggestions.

Thanks and regards,

Pradip

[agentry_src · Accepted solution]

Hi Pradip,

The MDO usage depends on your system architecture. However, there are several things to consider with MDO. If you routinely download Production Orders or other objects which change over time (schedule objects), then maintaining a local copy with MDO is a big help. Similarly for things like Quality test results from a LIMS or similar system.

One caution is that doing joins with MDO objects are difficult and require using the XML tools in the workbench. Those types of joins are not going to perform anywhere near as well as a database table join.

So for performance considerations, you may still want to keep the data in a database and use custom views, stored procedures, or other custom features of the database.

Hope this helps address your question.

Regards,

Mike

[Former Member · Accepted solution]

Hi Mike,

Thanks a lot for such a helpful answer. It is true that in validation scenario we need several joins. So, that is where MDO is not much acceptable.

In case of transaction data if I need to keep several states of the document out of ECC and post it at a time in ECC.

Example: I keep the LIMS data as inspection lot characteristics for a batch in MII connected SQL data base. But I do not send the detail in ECC. In the next step we send the data to ERP during Result recording.

In this case MDO is a very nice solution to use.

But if the business needs to track that intermediate step of inspection lot before Result recording then we need to keep the history of the document for a longer time frame.

In that case is it suggested to use MDO when we need to keep the data for more than an year?

Also if we need archiving of data after some time how MDO is better than the Data Base?

Waiting for the suggestion.

Thanks and regards,

Pradip

[agentry_src · Accepted solution]

I am not sure MDO is desirable for year long retention, but theoretically you could do that.

A more reasonable scenario would be to have updates done periodically to repopulate MDO with the latest data. MDO will hold the most recently cached data if an update is not successful, so your most recently updated data will always be available locally. This is where downloading Orders from ECC via MDO comes in handy.

I don't know whether there is an argument for archiving in MDO instead of the database. For archiving, I would lean towards the database or even off database backups or flatfiles, but I am not sure I understand your scenario well enough to make a good suggestion.

Regards,

Mike

Edited by: Michael Appleby on May 19, 2011 5:16 PM

[Former Member · Accepted solution]

Hi Mike,

Thanks a lot. My question is answered properly. So MDO is an intermediate object above the data layer. It does not replace any Data source like SQL.

To do a better design and creation of a Light Production or Process Execution system we still need a Data base and place the MDO just below the UI layer.

Waiting for your suggestion.

Thanks and regards,

Pradip

[agentry_src · Accepted solution]

I think it boils down to MDO does not replace all the functions and features you get (and probably need) from a relational database.

But it is a powerful and useful tool for local data retention in place of the database.

Regards,

Mike

[Former Member · Accepted solution]

Hi Mike,

Thanks a lot for all the suggestions. All the inputs will help to design a very good application using MDO.

Thanks and regards,

Pradip