Developing
Mobile Solutions for MI | Application
Deployment | MI Web
Console | User-dependent
Data Filtering
Mobile Component Descriptor (MCD)
Introduction
Mobile applications span over several systems: a Java part on the mobile
device, customizing or code on the WebAS and business logic in the application
backend. Only if all pieces are in place and are properly set up, the mobile
solution as a whole works. To manage mobile solution in their entirety, MI uses
a special object: the Mobile Component Descriptor (MCD).
In the following chapter, you'll learn
- What the Mobile Componet Descriptor is
- How the MCD is used in your mobile projects
What is the Mobile Component Descriptor?
In order to ensure that a mobile solution is running, the following application
parts need to be in place and be set up properly:
System
instance |
Required application piece |
Mobile device |
- Application archive (.war/.jar) of the mobile application (optionally
including meRepMeta.xml for Smart Sync)
- MI Client on the mobile device in the correct version and patch
level for this application
|
Web AS 6.20 |
- Application archive in the virtual file system of the SAP J2EE Engine
in order to allow for application deployment
- Generic Sync:
- mapping entries (table BWAFMAPP)
- RFC destination to application backend (table MEMAPPDEST)
- Smart Sync
- Definition of all SyncBOs used by the mobile application
- Generated and configured runtime agents for these SyncBOs
- Offline Minapp (optional; only if mobile application needs to be
deployed via role)
- Mobile Component Descriptor
|
Application backend |
- Server-side Business logic of mobile application
- Generic Sync: Wrapper functions and function modules that make
the business logic
- Smart Sync: BAPI Wrappers and BAPIs
- Customizing for the application in the application backend
|
Furthermore, several non-application parts need to exist or be set up like
- a user on Web AS and application backend with all necessary authorizations
- optional: a role on Web AS or application backend can exist that assigns
the mobile application to the user
- optional: flag on the application version, which version is to be deployed
on role-based deployment of the application
- Deployment definition for the user or role
Obviously, there is the need to manage all these cross-dependencies of the
various pieces that make a mobile solution. The Mobile Component Descriptor
is exactly that managing instance and contains information on the following:
- Header information (namespace, name, version)
- Properties (Runtime type, application type, build no. etc.)
- Dependencies (required SyncBOs and MCDs (for example MI Client versions
and patches), relevant authorization objects etc.)
- Customizing (Download location on the virtual file system, flag for role-based
deployment)
The graphic below illustrates this concept:

The MCD is designed in a flexible way to allow description of future parts
and dependencies of a mobile solution and its enhancement by a applications.
The MCD information for applications are used for various purposes:
- Only valid applications (that means applications with a valid MCD entry)
can be assigned to users in the Web Console. It is also checked, if the application
exists in the specified version. This means that without the MCD, applications
cannot be deployed.
- Dependencies between mobile components are evaluated and dependent components
are automatically deployed together with the assigned component
- Authorization objects that are declared in the MCD are evaluated and the
relevant user authorizations for all application users on the device are automatically
downloaded as well (Click here
to read more on authorizations)
- MCD information is exchanged during synchronization between MI Client and
Web AS. If the server detects that applications are not yet installed or installed,
but in a different version, an automatic installation of the correct application
version is initiated.
 |
MCD are created, changed, transported and
deleted via the MCD Editor (transaction MI_MCD). All applications should
ALWAYS ship MCD together with the application archives.
Contrary to ME 2.1, the Web Console should only be used to upload the
application archive via and thus link it to an already existing MCD. The
button 'Upload application' in the Web Console should never be used. |
Using the MCD in your mobile projects
The lifecycle of an MCD is as follows:
- MCD is created by the responsible developer at the beginning of the development
project
- During development, dependencies of the MCD are added as needed
- At the end of development, the MCD is transported. The application archive
is built.
- MCD transport and application archive are shipped to the customer
- The customer's administrator applies the MCD transport
- The administrator uploads the application archive to the MCD in the Web
Console
- The administrator assigns the MCD to users and/or roles
- Users synchronize to download the application archive
 |
If application archive or MCD needs patching,
this ALWAYS results in a NEW MCD version and a NEW application archive
that belongs to this MCD version.
|
Find more information on the Change & Transport System of the WebAS here.