Explaining the Mobile Application Integration Framework (MAIF)

Mobile application is an essential concept in MAIF. MAIF manages users, configuration data, and application runtime data using mobile application. There are several types of mobile applications in MAIF. SAP Service and Asset Manager is an OData application, as MDK-based applications use OData services for back-end integration.

For each SAP Service and Asset Manager release, a new mobile application is created. This allows multiple releases of SAP Service and Asset Manager to run in the same customer SAP system in parallel. Configuration objects for each mobile application use a naming pattern.

MAIF creates a mobile user for every user of a mobile application. A mobile user is an enhancement to the standard SAP user concept. A mobile user is the unique identity of an SAP user ID combines with a mobile application, and a mobile device.

Some important attributes about offline mobile user:

Named SAP user

Every mobile user must map to a unique SAP user ID. Sharing a single mobile user ID by multiple users must be avoided. Principle propagation setup in SAP Business Technology Platform Mobile Services and SAP Cloud Connector is required.

Update authorization

All standard SAP user authorization profiles and restrictions apply to the mobile user when updating data in SAP.

Read authorization

Offline mobile application user can read data that are available on mobile device. Data read access control is handled using data distribution rules to prevent unauthorized data being downloaded to a mobile device.

Mandatory Authorization

SAP Service and Asset Manager user must have authorization with authorization object ‘/MERP/SAM’, id ‘ACTVT,’ value ‘16’ assigned.

Persona Assignment

SAP Service and Asset Manager supports multiple personas to be assigned to a user. When the user is assigned more than one persona, they can switch personas on the Mobile Client via Profile Settings. However, when you want to restrict a user to a specific Persona tha you can assign through Authorization Profile and User Roles or through the Syclo Admin Portal.

Mobile user registration

A mobile user is created by the user registration process. This is handled either automatically by MAIF or manually using the User Management function in MAIF (tcode "/SYCLO/ADMIN" ).

Mobile user attribute

These attributes are specific to the mobile user. Mobile user attributes are defined for a mobile application in configuration, and can be assigned to an individual mobile user at runtime. They can be accessed and maintained using the User Management function in MAIF (tcode "/SYCLO/ADMIN").

Offline mobile application like SAP Service and Asset Manager must synchronize mobile device with SAP system to download necessary data to work offline.

There are two types of synchronization in the offline synchronization cycle:

Initial Sync

This is the first sync with SAP back-end system that user performs after the app is installed, or after user performs a device reset to clear the offline database. Initial sync happens only once in a sync cycle. It is also the most expensive sync cycle, as all data needed on the device must be downloaded, which can be large volume, and can take significant time to complete.

Delta Sync

This includes all subsequent syncs with the SAP back-end system after the initial sync. Delta sync occurs repeatedly in sync cycle. Delta sync must download only incremental data changes to the mobile client. If there has been no change in the SAP back-end system since the last delta sync, then an empty delta sync occurs, with nothing downloaded. Delta sync is very efficient and highly optimized. It usually takes less time to complete.

For OData based application like SAP Service and Asset Manager, delta token is used by data distribution algorithm to calculate the incremental changes for entity set.

This contains:

• xChange Trigger: This is the listening agent to the SAP data object update process. It should be invoked whenever an SAP data object is created, changed, or deleted. Its technical implementation is dependent on the SAP data object and update business logic, but is independent of the mobile application, and reusable by different mobile applications.

• xChange Handler: Provides the technical implementation of the change detection for an SAP data object. MAIF xChange handler must be a subclass of base handler /SYCLO/CL_CORE_EX_HANDLER_BASE. xChange handler is mobile application independent and reusable by different mobile applications.

• xChange Table: Persistent table in SAP system storing SAP data object change detection result. Typically only minimum information about SAP data object is stored, such as object key, change timestamp, and change action indicator such as Insert, Update or Delete. xChange table must conform to a standard structure, with key structure /SYCLO/CORE_EXCHANGE_KEY_STR, and include structure /SYCLO/CORE_EXCHANGE_SUB_STR as attributes. It is mobile application independent.

• xChange Object: This is the configuration object that controls the runtime change detection behavior for a specific mobile application, such as trigger condition, data filter rules, SAP data object attribute level change detection setting, and so on. It is mobile application dependent.

MAIF has defined a standardized implementation pattern for OData service.

1. OData V2 services:

   All MAIF based OData services are based on OData V2. Some of the advanced features required for OData offline applications are not yet supported in SAP Gateway using OData V2.

2. Generic Model Provider and Data Provider:

   All MAIF-based OData services use the common generic model provider class /MFND/CL_CORE_ODATA_V2_MPC and data provider class /MFND/CL_CORE_ODATA_V2_DPC. Business logic implementation is done using OData Mobile Data Object (oMDO) configuration objects and oMDO ABAP OO handlers.

3. Application-specific OData service:

   While business logic implementation can be reused by multiple apps, MAIF OData service is application-specific. Each OData service is assigned to a single application.

   For SAP Service and Asset Manager, each release has its own dedicated OData service.

4. OData model definition:

   

   MAIF OData model is defined by customizing configuration, using MAIF central configuration tool (IMG → Mobile Application Integration Framework Configuration → oData Integration Settings → oData Model Definition).

   The generic MAIF model provider class generates the OData model dynamically based on the model configuration.

   MAIF OData model entity type definition must be mapped to a technical entity model and type that is implemented by the oMDO handler. While MAIF OData model entity type is application-specific, oMDO handler and its technical entity model and type are reusable by multiple applications.

5. oMDO handler:

   This is the technical building block for MAIF OData service business logic layer. oMDO handler is designed based on SAP business object definition, and support CRUD operations of SAP business object through the technical entity model. It is the technical foundation of MAIF OData service.

   oMDO handler must be subclass of oMDO base class /MFND/CL_CORE_OMDO_HNDLER_BASE.

6. oMDO Configuration Object:

   oMDO configuration object defines the runtime functionalities of a MAIF OData service for a mobile application, including essential offline mobile application features data distribution rules, server-side paging, delta sync support, client state management, dependent object and transaction merge,

7. OData service composition:

   

   Multiple component services can be combined into a single OData service for runtime mobile application consumption using service composition.

• Client State Management:

  

  MAIF OData client state management allows the tracking of entity set object keys distributed to OData service consumer for each synchronization cycle, along with supporting information such as data distribution rules used for the calculation. This information is essential in delta sync object key list calculation and tombstone calculation for deleted entity keys.

  Client State Monitor is provided in MAIF Administration and Monitoring tool for viewing details of captured client state.

  Enabling of client state tracking is controlled by oMDO configuration. Once enabled, tracking is done automatically by MAIF runtime service, identified using Client State Id.

  Data Purge–Client state table size grows over time. Client state history must be purged regularly to maintain optimal runtime performance. Use the system program /MFND/CORE_CLNT_ST_PURGE_PROG to purge client state history records.

• Dependent Object Management:

  

  In complex data synchronization scenarios like offline mobile applications, data distribution of different SAP business objects might have interdependency.

  For example, in SAP Service and Asset Manager, distribution of equipment object records has dependency on distribution of work orders and notifications assignment to the mobile user. Distribution of measuring point object records has a dependency of equipment data distributed.

  MAIF supports such complex data distribution with oMDO dependent object configuration. Once configured, information is captured in a dependent queue automatically by MAIF runtime. oMDO handler must implement SAP business object-specific logic to consume information from dependent object queue.

  Dependent Queue Monitor is provided in MAIF Administration and Monitoring tool for viewing details of dependent queue.

  Data Purge–Dependent queue grows over time. Dependent queue history must be purged regularly using the system program /MFND/CORE_DEPOBJ_Q_PURGE_PROG.

• Delta Token:

  Use of delta token is essential in offline mobile application. MAIF determines synchronization cycle based on whether $deltatoken is provided in OData GET request.

  Delta token generation must be enabled in oMDO configuration, using setting ‘Support Delta Sync.’ MAIF generates $deltatoken automatically using the following format:

  Code Snippet

  Copy codeSwitch to dark mode

  1
  Client State Id (C32) + Sync Time (YYYYMMDDHHMMSS)

• Server-Side Paging:

  

  Server-side paging allows the split of OData service response payload into packages, using $skiptoken. This is necessary for entity sets with large data distribution.

  MAIF provides standard support for server-side paging. Enable paging in oMDO configuration.

  Data Purge–Table with server side paging list grows over time. It should be purged regularly using system program /MFND/CORE_SVR_PAGE_PURGE_PROG to purge server-side paging list history.

• oMDO Processing–Basic Flow:

• oMDO Processing–Standard Flow:

  

  oMDO data distribution using standard flow is suitable for business objects with large data volume, complex distribution rules, and frequent changes. Master data and transactional data are some examples.

  oMDO handler implementing standard flow is subclassed from /MFND/CL_CORE_OMDO_HNDLE_BASE, following implementation pattern using object key list calculation. MAIF runtime supports server-side paging by default using standard flow.

Use MAIF push framework, push notifications can be generated and send to SAP Business Technology Platform Mobile Services based configured change conditions for various SAP business objects.

MAIF provides a central configuration tool ConfigPanel for all customization and configuration changes. You can access the configuration tool via IMG → Mobile Application Integration Framework Configuration or use tcode: /SYCLO/CONFIGPANEL.

For all MAIF-related runtime administration and monitoring, using the central Administration and Monitoring tool. You can access the tool using tcode /SYCLO/ADMIN.