Skip to Content
In a post here: Was dem einen recht ist, ist dem anderen billig and a series of posts here: The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 12) The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 12) The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 11) The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 10) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 9) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 8) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 7) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 6) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 5) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 4) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 3) 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 Enterprise SOA 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.)

To report this post you need to login first.

2 Comments

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

  1. Wolfgang Valtin
    Hello David,
    To get a list of tables involved in SMLT is easy: Just select one of the already imported packages and you’ll see the transport – which contains 9 (!) other transports. Now you may select one of those transports and check the transport objects. If you want more comfort guess in one or two days you could’ve a utility which gives you a list of tables involved. But –
    would it make you really happy to know that some 3567 tables are filled in SMLT, among these the tables T7TW4Z and T16CT ??? 
    Think the point is that there no reliable data models for SAP-applications.
    Regards WOlfgang
    (0) 
    1. David Halitsky
      Thanks very much for taking the time to answer.

      But the list of tables I’m talking about is not the one that would show all tables which CAN be processed by SMLT.

      It’s a list that a client would prepare in order to tell SMLT that only certain tables SHOULD be processed. 

      According to a very experienced consultant at my current site, it’s pointless to let SMLT process all tables, since few if any clients use all of the tables involved, even within a given application area.

      Anyway …

      with regard to your general point about availability of reliable data-models for SAP app’s, this is a KEY differentiator between SAP and Oracle (or at least was, six years aqo.)

      As of 6 years ago, Oracle would at least provide ONE print copy of the relevant data model at contract closure.

      At the same time, SAP consultants were offering the usual reasons for not doing even this much:

      a) it’s dangerous for customers to know the tables – just use the structures (e.g. postab, etc.)

      b) it’s dangerous for SAP to let its data model “out”.

      In my opinion, there are both pretty lame excuses that are left-overs from a time when SAP did not really need the cooperation of IT-savvy customers.

      But as I’ve already said several dozen times here at SDN, how can an IT-savvy customer help SAP by writing efficient data retrieval services in an ES(O)A environment if the data models aren’t available?

      Yes – I know that that the $150-$300/hr consultant crowd would complain if the data models were made public.

      But SAP is going to have to decide who is more important to its future:

      a) consultants whose worth is based on the “closely-held” knowledge that they gave

      b) consultant whose worth is based on what they can do if such knowledge were made available to everyone.

      Thanks again for taking the time to reply.

      djh

      (0) 

Leave a Reply