Skip to Content
0
Former Member
Dec 07, 2006 at 05:41 PM

How to prepare for SMLT: repost of post from the blogs

34 Views

In a post here:

<a href="/people/david.halitsky/blog/2006/11/08/was-dem-einen-recht-ist-ist-dem-anderen-billig

and a series of posts here:

<b><font color=blue>

<a href="/people/david.halitsky/blog/2006/11/16/the-diachronic-metadata-repository-dmdr-as-a-tool-for-risk-reduction-via-conflict-prevention-during-legacy-to-erp-conversions-part-12:Part13</A>

<a href="/people/david.halitsky/blog/2006/11/16/the-diachronic-metadata-repository-dmdr-as-a-tool-for-risk-reduction-via-conflict-prevention-during-legacy-to-erp-conversions-part-12:Part12</A>

<a href="/people/david.halitsky/blog/2006/11/14/the-diachronic-metadata-repository-dmdr-as-a-tool-for-risk-reduction-via-conflict-prevention-during-legacy-to-erp-conversions-part-11:Part11</A>

<a href="/people/david.halitsky/blog/2006/11/07/the-diachronic-metadata-repository-dmdr-as-a-tool-for-risk-reduction-via-conflict-prevention-during-legacy-to-erp-conversions-part-10:Part10</A>

<a href="/people/david.halitsky/blog/2006/11/06/the-diachronic-metadata-repository-as-a-tool-for-risk-reduction-via-conflict-prevention-during-legacy-to-erp-conversions-part-9:Part9</A>

<a href="/people/david.halitsky/blog/2006/10/31/the-diachronic-metadata-repository-as-a-tool-for-risk-reduction-via-conflict-prevention-during-legacy-to-erp-conversions-part-8:Part8</A>

<a href="/people/david.halitsky/blog/2006/10/30/the-diachronic-metadata-repository-as-a-tool-for-risk-reduction-via-conflict-prevention-during-legacy-to-erp-conversions-part-7:Part7</A>

<a href="/people/david.halitsky/blog/2006/10/27/the-diachronic-metadata-repository-as-a-tool-for-risk-reduction-via-conflict-prevention-during-legacy-to-erp-conversions-part-6:Part6</A>

<a href="/people/david.halitsky/blog/2006/10/26/the-diachronic-metadata-repository-as-a-tool-for-risk-reduction-via-conflict-prevention-during-legacy-to-erp-conversions-part-5:Part5</A>

<a href="/people/david.halitsky/blog/2006/10/24/the-diachronic-metadata-repository-as-a-tool-for-risk-reduction-via-conflict-prevention-during-legacy-to-erp-conversions-part-4:Part4</A>

<a href="/people/david.halitsky/blog/2006/10/20/the-diachronic-metadata-repository-as-a-tool-for-risk-reduction-via-conflict-prevention-during-legacy-to-erp-conversions-part-3:Part3</A></font></b>

I suggested that SAP does not make its own metadata sufficiently transparent to support all activities requiring knowlege of SAP architecture, particularly activities such as "AsIs:ToBe" mappings in Legacy -> ERP conversions, or creation of ES(O)A services.

So I'd like to share something that recently happened at work, in order to illustrate this point.

The customer is opening a plant in a different country and must run SAP in a different language.

So the first thing it wants to do is run SMLT with a list of tables that are involved in the transactions which will be run in the new language.

Ah - but how to get this list of tables ...!

Shouldn't there be an absolutely transparent utility which takes the set of transactions from the blueprint and produces a list of tables that need to be fed to SMLT to support these transactions?

Alternatively, shouldn't SAP "open up" the metadata and metaprocesses behind the Repository Information system, so that an enterprising customer can write such a utility itself?

Am I missing something here?

If so, I've posted this post in the ABAP General Forum also, so that anyone who wants some points can tell everyone how and why this problem is really not a problem. (If more than one good solution is posted, I promise I'll ask Craig/Mark to award "10" to each one.)<br><br>