Purpose
The tool lists the objects which could be critical in client scenariosor must be monitored. Mainly application tables (for master andtransaction data) and customizing object definitions are analyzed. Otherobjects in the specified selection set are ignored. Application tablesare recognized by their delivery class, i.e. this table attribute in theDictionary. Customizing objects are recognized from the customizingobject definitions in the transaction SOBJ.
The object set to be analyzed is specified by parameter. It is usuallyselected from one or more transport requests containing object lists ofa product to be delivered (first parameter). Alternatively, a set ofpackages can be specified (second/third parameters).

Results list structure
The analysis poses the following three questions:

• (Q1) Are there any cross-client application tables with delivery class
A?

• (Q2) Are there any cross-client customizing objects? Which customizing
tables do they contain?

• (Q3) Which other cross-client customizing tables without reference to
customizing objects and IMG are there?
The results list has 3 corresponding sections containing the table orcustomizing objects found, with their source information such ascomponent, development class (package), person responsible in the objectdirectory table TADIR. In the Q2 section, the customizing objects arealso resolved into their component views and tables.

Column headers
All three sections have the following columns, which are not all usedfor all object types.
Name of the object described in the row. followed by its views andtables for customizing objects,
'Type': Customizing maintenance type (acc. to SOBJ definition),
'DelivCl': Delivery class or customizing category,
'Cli': Client-specific ("X") or cross-client (space),
'IMG': Maintenance activity for the object in IMG flag,
'Component': Application hierarchy component,
'DevClass': Development class (package),
'Text': Short description of the object or subobject,
'Author': Person responsible for the object in TADIR and possibly theperson responsible for the development class as well
List Header
The list header contains statistics about the scope of the analysis set,including the number of cross-client application tables and customizingobjects. This lets you estimate the total scope of the product area tobe analyzed.

List analysis aims
If Q1 finds objects, the application is probably not multiple-client-capable for these tables if their analysis class is really 'A'(Application Data). In this case, contact the developer to find outwhether the application can run with multiple clients without datasecurity risks. If the table is in the standard SAP delivery, you cancontact me. I have a list of tables which which have been incorrectlygiven delivery class 'A', which you can ignore (being corrected inSupport Packages).
Objects from the other two questions, Q2 and Q3, initially only indicatethat there are cross-client settings in the customizing environment.Such objects are not a priori problematic, some settings are correctlymade to cross-client entities (e.g. all types of technical systemsettings), but such objects must be clearly identified as cross-clientobjects and it must be clarified for an multi-client ASP whether therecan be conflicting requirements from different clients and under whatcircumstances. You must establish:


• Which functions the object performs. Do they only affect individual
clients, leaving the other clients unaffected by changes to thesettings?

• If so: How should an ASP deal with heterogeneous client requirements in
a scenario to ensure the coexistence of the clients?
If such settings describe organizational elements of a company, orconcern company-specific procedure control, check whether customizingcan be performed safely (data isolation) and conveniently enough in anASP multi-client scenario for the individual clients, or whether thecross-client design decision is questionable, and a multi-client problemis to be expected.

Prerequisites
The ASP solution to be evaluated must be selectable in the system. Youcan usually identify the ASP solution in an SAP System via an objectlist in the form of one or more transport requests which contain allobjects and customizing entries for the solution completely andexclusively, i.e. the object list contains no objects which are not partof the ASP solution.
A client transport is not a reliable transport request because itcontains the entire SAP System and the ASP solution cannot beidentified.
An ASP solution is often a set of preconfigured customizing settings fora particular application scenario. The object list then only containsentries from customizing tables and customizing objects (one or morelogically-connected entries from one or more customizing tables). Inthis case you can use the first tool program (MC_TABKEY_ANALYSIS).
In other cases, the solution also contains Repository objects(especially Dictionary objects, programs or customizing objectdefinitions). These can be checked, in addition to the previouslymentioned table checks, by the second tool (MC_METADATA_ANALYSIS). Thistool analyzes and displays potential metadata multi-client-compatibilityconflicts.


• Transport request parameter: (can be several)


• Component/package parameter: Application component or package

Output
The results list begins with a statistical overview of the analyzedclient-specific and cross-client objects.