Purpose
The tool returns a list of objects which could be critical inmulti-client scenarios. Only application tables (for master andtransaction data) and customizing object definitions, are examined, allother selected objects are ignored. Application tables are identified bytheir delivery class attribute in the Dictionary. Customizing objectsare identified from the customizing object definitions created in thetransaction SOBJ.
The objects to be examined are specified by parameter. They are usuallyselected from one or more transport requests containing piece lists fora product to be delivered (first parameter), or you can also specify aset of packages (second/third parameters).

How is the results list structured?
The analysis answers the following three questions:

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


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

• (Q3) What other cross-client customizing tables without reference to
customizing objects and IMG are there?
The results list comprises 3 corresponding sublists. Each sublistcontains the tables or customizing objects found and their sourceinformation, e.g. component, package, person responsible for the objectin object catalog table TADIR. The Q2 sublist also resolves thecustomizing objects into their component views and tables.

Column headings
All three sublists have the following columns, which are not all usedfor all object types.
The first column contains the name of the object in the row. Forcustomizing objects the views and tables it contains follow,
'Type': Customizing maintenance type (acc. to SOBJ definition),
'Del. Cl': Delivery class or customizing category,
'Cli': Client-specific ("X") or cross-client (space),
'IMG': The object has a maintenance activity in the IMG,
'Component': Application hierarchy component,
'DevClass': Package,
'Text': Short description of the object or subobject,
'Author': Person responsible for the object according to TADIR, possiblyalso the person responsible for the package
List header
The list header contains additional statistics about the scope of thedata analyzed, including the number of cross-client application tablesand customizing objects. You can estimate the amount of data to beanalyzed in your product area from this data.

List analysis
If objects have been found for question Q1, the application is probablynot multi-client capable for these tables , if the analysis class of thetables really is 'A' (application data). In this case, contact thedeveloper to find out whether the application can run in a multi-clientenvironment without data security and data protection risks. If thetable is in the SAP standard delivery, you can contact me. I have a listof tables which have been incorrectly assigned to delivery class 'A',and can be ignored (being corrected in Support Packages).
Objects for the other two questions Q2 and Q3 initially only mean thatthere are cross-client settings in the customizing environment. Suchobjects need not be errors, because some settings are intended forcross-client entities (e.g. all types of technical system settings), butsuch objects must be clearly identified as cross-client objects andexplained for an ASP with a multi-client system whether conflictingrequirements from different clients are possible, and what is to be bornin mind in this case. The explanation must include:


• Which functions are described by the object? Do they only affect
individual clients, leaving the other clients unaffected by changes inthe settings?

• If so: how can an ASP avoid conflicting client requirements in a
scenario and guarentee the coexistence of the clients?
If such settings model organization elements of a company or controlcompany-specific procedures, you must analyze whether customizing of thevarious clients can be performed safely (data isolation) and efficientlyenough in an ASP multi-client scenario, or whether the cross-clientdesign decision must be questioned, i.e. whether client conflicts couldoccur.

Prerequisites
The ASP solution to be analyzed must be present and selectable in thesystem. It can usually be identified in an SAP System by a piece list,in the form of one or more transport requests which contain the solutionobjects and customizing entries
- completely and
- exclusively, i.e. there are no objects in the piece list which are notpart of the ASP solution.
So a client transport in particular is not a valid transport request,because it contains the entire SAP System and the ASP solution cannot beidentified.
In many cases, an ASP solution is a set of preconfigured customizingsettings for a particular application scenario. The piece list onlycontains entries for customizing tables and customizing objects (one ormore logically-related 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 by the second tool(MC_METADATA_ANALYSIS), in addition to the previously mentioned tablecontents check. This tool analyzes and displays potential multi-clientcapability conflicts in the metadata.

Input Parameters (can also be entered generically and bylisting):


• Transport Request: can be more than one


• Component/Package: application component or package

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