ShopFloorManagerConfigurationGuide en
ShopFloorManagerConfigurationGuide en
1 Document History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.1 SAP Gateway Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
7.2 SAP Gateway Error Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.3 SAP Gateway Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.4 SAP Gateway Tracing Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Before you begin reading this guide, be sure that you have the latest version.
The following table provides an overview of the most important document changes.
The SAP Shop Floor Manager Configuration Guide is intended for system administrators, technical architects,
implementation team members, and IT personnel involved in the installation, setup, and configuration of
software for the application.
It is assumed that the personnel performing the installation and setup are familiar with SAP installation
guidelines. SAP setup knowledge is helpful while carrying out the steps for the mobile setup of SAP.
Use the SAP Shop Floor Manager along with appropriate SAP documentation. Note that this guide only covers
setting up and enabling the SAP Shop Floor Manager mobile application.
SAP Shop Floor Manager Version 1.0 supports the following back-end systems:
Note
For SAP S/4HANA on-premise 1909 systems, no ABAP add-on installation is required. Check 2493602
, including the prerequisites section. For the SAP S/4HANA on-premise 1909 release, SAP Shop
Floor Manager is only available in SAP S/4HANA 1909 FPS01 and above releases.
● SAP Enhancement Package 7 for SAP ERP 6.0 Support Package 14 or higher
● SAP Enhancement Package 8 for SAP ERP 6.0 Support Package SP07 or higher
SAP Shop Floor Manager is a mobile solution for managing production orders, notifications of the following
types: quality, maintenance, and shift notes.
Regardless of connectivity, SAP Shop Floor Manager allows remote employees to access, complete, and
manage their assigned production orders and notifications through their mobile devices. With SAP Asset
ManagerSAP Shop Floor Manager, they have SAP back end data readily available. Armed with more
information, employees work smarter, have more work time, improve their first-time fix rates, and extend asset
lives by conducting more preventative maintenance.
The main features and functions available in SAP Asset ManagerSAP Shop Floor Manager include the following.
SAP Shop Floor Manager supports the following standard SAP Plant Maintenance productionorder
functionalities on the mobile device:
The following standard SAP notification functionalities are supported on the mobile device:
Single Sign-On (SSO) allows the user to log into the SAP Shop Floor Manager application from the client using
SSO credentials without having to enter their back end user name and password. In addition, once logged in
with SSO, you can access another mobile application without the need to log in again.
Documents
SAP Shop Floor Manager supports viewing of master data or transaction data attachments on the mobile
device. Documents include Microsoft Office files, PDFs, and other commonly used business documents,
including videos, pictures, and audio files.
Downloading and uploading documents are supported for the following objects:
● Notifications
SAP Shop Floor Manager uses the SAP back end and specific SAP ERP transaction codes to help configure the
application.
The current version of SAP Shop Floor Manager has the following limitations with Notification maintenance:
● Shift Notes: Reference Production Order ID cannot be changed for the existing Shift Note
● Quality Notifications: Partner determination must not be mandatory, otherwise Quality Notification cannot
be created
The SAP Mobile Add-On provides integration services for SAP Shop Floor Manager. A central configuration tool
known as the SAP Configuration Panel is provided to perform all configuration tasks related for the mobile
application. The Configuration Panel is a browser-based application based on Web Dynpro ABAP.
Context
You can access the Configuration Panel either through SAP Customizing or using a transaction code directly.
First, log into your back-end system, and then you can choose from the following two options:
Procedure
1. To access the ConfigPanel through Customizing, enter the transaction spro to open the Customizing:
Execute Project screen. Select the SAP Reference IMG tab. Using the SAP Customizing Implementation
Guide list, select Agentry SAP Framework Configuration System Settings Define Mobile
Applications .
2. To access the ConfigPanel using a direct transaction code shortcut, enter /n/syclo/configpanel.
Results
All configuration activities for the SAP Mobile Add-On are performed through the ConfigPanel.
Customization changes you make via the ConfigPanel can significantly impact the behavior of the SAP Mobile
Add-On and the SAP Shop Floor Manager application. Always follow SAP best practices, make changes and
test them in the development and quality control systems before you transport the changes into your
production landscape.
While configuration for each mobile application is unique, certain toolbar functions in the Configuration Panel
are common and are available for all applications.
If more than one mobile application is available in the same system, you can use the filter function to only view
items for a specific application. Find the filter option on any page where multiple applications are displayed.
To filter by application, click the arrow to the right of the Defined Mobile Applications field, and select the
appropriate mobile application. To remove the selection and view all items for all mobile applications in the
system, click in the field again and select the asterisk ( * ) symbol.
The following standard actions are available to configure different components and items within your mobile
application setup:
Once you click the Create, Copy, or Change button, the Save and Cancel buttons are displayed. After you
change the configuration of the item, click Save to save the changes or Cancel to discard the changes.
If the Save and Cancel buttons are active, the Home link for the ConfigPanel is not available. Either save
your changes or cancel out of the changes to return to the main Configuration Panel page
Message List
Certain actions can generate system messages. These messages can be error messages or informational
messages. If you perform an action that prompts a system message, a message bar appears above the main
panel with a brief description of the message.
Click the Show List button to display the detailed view of the message list.
The Mobile Application Configuration page allows you to configure general settings for the entire mobile
application.
● General
● Conversion Exit Setting (not used in SAP Shop Floor Manager)
● System Components (not used in SAP Shop Floor Manager)
● Parameters
● Client Globals (not used in SAP Shop Floor Manager)
● User Attributes (not used in SAP Shop Floor Manager)
General Tab
Use the General tab to create or change basic information about a mobile application.
● Basic Data section: Enter the name of the mobile application in the <Mobile Application> field, which
is limited to 40 characters. Select the type of application in the <Type> field. Note that for SAP Shop Floor
Manager, the type is <oData Applications>. Enter a brief, easy to understand description in the
<Description> field, limited to 60 characters. Type in the release number of the application in the
<Release> field.
● User Management Setting: When the <Disable Automatic User Creation> box is checked, a new
user GUID is not automatically created when a new mobile client is detected in the system. Manually create
and maintain mobile users through the Administration portal.
● Server Management Setting: When the <Disable Automatic Server Registration> box is
checked, a new server GUID is not automatically created when a new server is detected in the system. You
must manually create and maintain servers through the Administration portal.
● Life-cycle management: When the <Application Blocked> box is checked, the mobile application is
disabled. The mobile user can no longer connect to the back-end system for the mobile application, and
Parameters Tab
● Mobile Application Info: The <Mobile Application> field is read only and is the name of the mobile
application. The <Mobile Application Description> is read only and is a brief description of the
mobile application. The <Release> field is read only and is the release number of the application.
Note
For information on setting user parameters, see the following security guides, depending on your
back end system:
○ Mobile Add-On for S/4HANA Security Guide
○ Mobile Add-On for ERP Security Guide
The <Rule ID> field contains the rule used at runtime. If you check the <Use Rule> box, the rule in the
<Rule ID> field is active.
Check the <Active Flag> box to ensure that the parameter is used by the mobile application. Inactive
parameters are not used by the application. When you check the <No Runtime Change> box, you cannot
override the value of the parameter. The configured value is always the value. If the box is not checked, the
parameter values can be overridden at runtime through synchronization processing.
Gateway OData services implemented using the Mobile Integration Framework for SAP are different from the
typical Gateway OData services.
The following requirements must be met for the Gateway OData services:
● Define the Gateway OData technical model using the generic model provider class of the Mobile Integration
Framework /MFND/CL_CORE_ODATA_V2_MPC. You can maintain the OData technical model with
transaction /IWBEP/REG_MODEL.
● Define the Gateway OData technical service using the generic data provider class of the Mobile Integration
Framework /MFND/CL_CORE_ODATA_V2_DPC. You can maintain the OData technical service with
transaction /IWBEP/REG_SERVICE.
● Assign the Gateway OData technical service to a mobile application by choosing the OData Service
Assignment in the ConfigPanel.
Service Assignments
You can define the following settings for the OData service assignment:
Composition Settings
With service component composition, you can compose a complex service using component services.
● Parent OData Service and Version: Parent OData service. Entity model of a child OData service is included
in the parent entity model. Association and navigation properties can be defined between parent service
and component service.
● Component OData Service and Version: Child OData service
● Enabled: If the checkbox is not checked, the entity model of the component service is not included in the
entity model of the parent service.
OData service implemented using the Mobile Application Integration Framework does not use the Gateway
Service Builder to define the OData model. Define the OData model using the OData Model configuration tool in
the ConfigPanel. The runtime OData model is generated dynamically based on the configuration settings. The
OData model configuration is mobile application-specific. You cannot share OData models across mobile
applications.
Define the OData model configuration settings through the following screens:
Entity configuration defines the OData entity type. Entity set configuration defines the OData entity set. In an
OData model configuration, each entity type is limited to one entity set. Reuse of entity types by multiple entity
sets or by different OData services is not supported.
● Entity Type Name: Case-sensitive name of the entity type. The name must be unique within the OData
service.
● Active Flag: If unchecked, the entity type is not included in the generated OData model
● Entity Type ID: Internal ID generated by the system to identify the entity type
● Mobile Application: Mobile application for the entity type. The OData model configuration is defined for
individual mobile applications. You can reuse the entity type name in different mobile applications.
● Internal OData Service ID: Internal OData service ID that identifies the OData service for which the entity
type is defined
● Service: Gateway technical service name of the OData service. Information is read-only.
● Version: Gateway technical service version. Information is read-only.
● OMDO ID: OMDO that provides business logic for the entity type and its entity set
● OMDO Entity Type: Technical entity type of the OMDO that is mapped to the OData entity type. Data for
the OData entity type is supplied by the OMDO entity type.
The following attributes are available for the Entity Set definition:
● EntitySet Name: Case-sensitive name of the entity set. Must be unique within the OData service.
● Creatable: If checked, creation (POST) request for the entity set is supported
● Updatable: If checked, update (PUT / PATCH / MERGE) request for the entity set is supported
● Deletable: If checked, deletion (DELETE) request for the entity set is supported
● Pageable: If checked, paging is allowed for the entity set read request
● Filter Required: Not applicable for SAP Shop Floor Manager
Property List
An association defines the relationship between two entity types, with one entity type as the principle entity
type, and the other as the dependent entity type. An association set defines the relationship between the two
entity sets of the respective entity types in the association. In an OData model configuration, associations and
association sets are child objects of an entity type, and each association can have only one association set
defined.
When you define an OData model to use with OData offline SDK client application, you also define referential
constraints for the association. Only key fields of the principle entity type can be used in referential constraints.
You can configure the following in the Association Set Info section:
You can configure the following in the Referential Constraints section (not pictured in detail in the example
screenshot):
A navigation property represents a link from the parent entity type to a related entity types.
You can define the following attributes for a navigation property in the Entity Type Navigation Properties table:
You can define the following additional settings for the OData model:
Use the following screenshot as an example. When a user posts a meter reading from their client, by default the
reading is posted to the default OMDO, which here is SAM<XX>_METER_READING. However, if the user is
reading a periodic meter, the reading is posted to the SAM<XX>_MR_PERIODIC OMDO, which is substituted for
the default OMDO through the use of custom headers.
An OData mobile data object (also known as OMDO) provides business logic for a business object used in an
OData-based mobile application. An OMDO provides both technical implementation and configuration support
OData requests for a business object are mapped to an OMDO object. The OMDO handler then processes the
requests for the OMDO object. For read requests, the OMDO handler considers and enforces the data
distribution rules and other configuration settings, and determines the proper output response. For create,
update, and delete requests, the OMDO handler creates or updates the SAP BusinessObjects in the back-end
system as requested in the OData requests, and provides the relevant response.
You can set the following attributes on the General Setting tab:
● OMDO ID: ID of OData Mobile Data Object; limited to 40 characters. The OMDO ID must be unique in an
SAP client, across all mobile applications, as namespace restriction is enforced. A customer-defined
OMDO ID must use the Y or Z namespace.
● Description: Short description of the OMDO, limited to 60 characters
● Mobile Application: Mobile application of the OMDO. An OMDO always belongs to a single mobile
application.
● OMDO Handler: An ABAP OO class that provides the technical implementation for the OMDO object. The
OMDO handler must be a subclass of /MFND/CL_CORE_OMDO_HNDLER_BASE. You can reuse an OMDO
handler to provide technical implementation for multiple OMDO objects.
● Process Flow: Determines how the OMDO handler processes OData entity set read requests. Based on the
process flow setting, different OMDO handler methods are invoked at runtime. The OMDO handler
determines which process flow it supports.
The Technical Model Info tab is a display only tab. This tab displays the technical entity model supported by the
OMDO handler.
An OMDO handler can declare data filters and parameters supported by its CRUD (CREATE / READ /
UPDATE / DELETE) operations. These filters are displayed on the Data Filter tab.
An OMDO handler can declare field catalogs supported for the READ operation. If there is a READ operation, by
default, all of the fields from the database tables related to the OMDO object are selected. Using the field
catalog, customers can control which fields are selected, and improve performance, as typically a mobile
application doesn’t require all of the fields.
You can enable change detection for the OMDO using the Change Detection tab.
● Check xChange Info: Applies to standard flow processing only. If checked, change detection info is
checked to determine the delta sync object key list.
● Lead xChange Object: xChange object that supplies the change detection information for the OMDO.
Information from the xChange table of the xChange object is read and used for the calculation of the delta
sync object key list.
In some business cases, the read request sequence for the OMDOs or SAP BusinessObjects is important, since
the data distribution object key list of a subsequent OMDO depends on the results or outputs of the precedent
OMDOs. The subsequent OMDO is treated as a dependent object of the precedent OMDO. The leading OMDO
is the source OMDO, as the output of the lead OMDO supplies information for the dependent OMDO.
Dependent object key information generated by the leading OMDO is stored in the dependent object queue,
and is used by the dependent OMDO during its read request processing.
For example, SAP Shop Floor Manager downloads detailed information for equipment and functional locations
used in production orders assigned to a technician. To fulfill this requirement, read requests for production
You can define the following settings for a dependent object of the current OMDO:
● Source Technical Entity Type: Source OMDO technical entity type that contains information required by
the dependent object
● Dependent OMDO ID: ID of the dependent OMDO
● Dependent Technical Entity Type: Receiving technical entity type of the dependent OMDO, for which
information from the source technical entity type is transferred
● Key Calculation Mode: Select the way the keys are passed to the OMDO. Key calculation is a dependent
object concept; how you set up your dependent object is based on your source object.
○ Source Entity Output: Input for the dependent key. Keys are calculated based on the source entity type
output.
○ Source Entity Type Distribution Key List: Dependent Object Key construction comes from the
distribution key list of the source entity type. Using this option always collects all the valid keys from
the source entity type.
○ Source Entity Type Output + Target Entity Type Client State: Similar to Source Entity Output plus the
previous client state of the target entity type. Here, what is being created for dependent object
collection is a combined collection of the source entity type output and the target entity type client
state records from the previous sync.
● Active Flag: Enable or disable a dependent object definition
You can define the following settings for the mapping info of dependent object keys in the Dependent Object
Keys tab:
● Source Type: Use option By Field Name if the information comes from a field of the source technical entity
type. Use option By Value if a constant value is used.
● Source Value: Constant value for a dependent object key field. This field is only relevant if the source type
is set to By Value.
● Source OMDO Field Name: Name of the source technical entity type field that supplies value for the
dependent object key. This field is only relevant if the source type is set to By Field Name.
You can define the following settings for the mapping info of origin object keys in the Origin Object Keys tab (not
shown in detail in the example screenshot). The origin object key identifies the source OMDO object that has
generated the dependent object key.
● Source Type: Use option By Field Name if the information comes from a field of the source technical entity
type. Use option By Value if a constant value is used.
● Source Value: Constant value for an origin object key field. This field is only relevant if the source type is
set to By Value.
● Source OMDO Field Name: Name of the source technical entity type field that supplies value for the origin
object key. This field is only relevant if the source type is set to By Field Name.
You can display the dependent object queues generated during client synchronization at runtime using the
Dependent Queue Monitor on the Administration & Monitoring Portal.
You can define settings related to transactions (CUD requests) on the Transaction Settings tab.
● Enable Transaction Merge: If checked, transaction requests for the same object that are received in the
same changeset are merged. Therefore, the number of requests processed by the OMDO handler is
reduced. The sequence of the transaction requests in the changeset is respected, with the attribute value
of the last transaction request as the final value for the attribute.
For example, for Object 123 the requests are as follows:
Request #1 CREATE 123 Request #1 CREATE 123 (attribute values from Request
#2 and Request #3 are merged into Request #1)
Request #2 UPDATE 123
Request #1 UPDATE 123 Request #1 UPDATE 123 (attribute values from Request
#3 merged into Request #1)
Request #2 UPDATE 123
An outbound trigger performs a function that is implemented by the outbound trigger handler. Outbound
triggers can be assigned to an OMDO. The assigned outbound triggers are invoked after OMDO processing has
been completed, based on the sequence of the assignment.
You can set the following attributes when assigning an outbound trigger to an OMDO:
● Technical Entity Type: Optional. If defined, the outbound trigger is invoked only if the specified technical
entity type was processed by the OMDO.
● OMDO Operation: Optional. If defined, the outbound trigger is invoked only if the specified OMDO
operation is processed.
● Outbound Trigger ID: Assigned outbound trigger ID
● Process Mode: Only the Always Run mode is supported
● Active: Enable or disable an outbound trigger
Change detection settings are used to define and configure how the mobile application, such as SAP Shop
Floor Manager, communicates with SAP and the object tables contained within SAP
● Exchange Object Configuration: Change detection rules for SAP data objects, such as master data and
transaction data, defined for each mobile application
● EFI Assignment: Enhancement framework implementation trigger assigned to exchange objects
Create tables and objects in SAP and the Mobile Development Kit before you can create or configure
information in the ConfigPanel.
Enhancement Framework Implementation (EFI) source code plug-ins are implemented by the SAP Mobile Add-
On for each business object where you configure change detection.
The source code plug-in is provided as an ABAP include file. Each exchange object is assigned to a plug-in to
handle the actual change detection process. EFIs are typically available across multiple mobile applications
running on the same system.
EFIs collect before and after images of data in an SAP object that was created, modified, or deleted. The EFI
then hands those images to the exchange object, which continues with the data processing. Therefore, link the
EFIs to their corresponding exchange objects.
The Enhancement Implementation Includes section is a tree of the include file list in the package. To expand
the list, click the arrow to the right of the item.
Use the General tab to view and modify the general settings for chosen EFI file.
● EFI Type: Select one of two options; Standard EFI Include or EFI Event Handler. Choosing Standard EFI
Include is the traditional way to implement EFI and configure the EFI assignments. Selecting EFI Event
Handler implements EFI using an ABAP class-based approach.
When you use a class-based approach, EFI implementation is developed as a subclass of /SMFND/
CL_CORE_EFI_EVENT_BASE. Available EFI event handler classes are displayed in the dropdown field. The
EFI class-based approach provides a more robust functionality and is recommended for a new EFI
implementation.
● EFI Include Name: File name of the source code plug-in
● Description: Short description of the EFI. The description field is automatically populated when you select
the EFI include name and is read only.
● Package: Package where the EFI is located. The package field is automatically populated when you select
the EFI include name and is read only.
Assignment Tab
The exchange object defines what in the exchange table is updated in the exchange persistent layer, what class
handler is called to update the exchange table, and what fields are related to the change detection.
Use the Configuration Panel to specify which changes are relevant to the mobile application and what
conditions to satisfy for so that an update action is triggered. The Exchange Object Configuration panel has the
following tabs:
● Technical Settings
● Change Detection Field Selection
● Change Detection Condition Filter
● Data Segment Settings
● Linkage Settings
Use the Technical Settings tab to configure basic settings for an exchange object.
Use the <Exchange Object> field for the ID of the exchange object, limited to 40 characters. Type in a
description in the <Exchange Object Description> field, limited to 60 characters. The <Mobile
Application> field contains a dropdown where you can select your mobile application. The <Application
Area> classifies the exchange object based on standard SAP application areas using a dropdown selection
field.
The <Reference Business Object> is the standard SAP business object. The <Exchange Table Name>
is the name of the table stored in SAP that contains the technical data. The <Exchange Table
Description> is a brief description of the exchange table. The <Exchange Lock Object> field is used
when updating the exchange table. Type in how many days you want to keep historical data in the <Days to
Keep History> field. Check the <No Exchange Table Update> checkbox to not write the record to the
exchange table in SAP when the record is changed.
● Handler Setting: Type in the name of the class handler from the repository that is responsible for updating
the exchange table in the <Exchange Object Handler> field.
● Collective Run Settings: Define the condition where xChange processing is executed asynchronously as a
V3 run by selecting one of the following mode options:
○ Dynamic: The collective run mode is determined at runtime by the xChange handler method
DETERMINE_EXEC_MODE
○ Not Allowed: Not allowed to switch to collective run mode
○ Activated: Always execute asynchronously in V3 collective run mode
○ By User Parameter ID: Switch to V3 collective run mode for runtime user with the specified user
parameter value set in the user profile
● Activation Setting: Check the <Active Flag> checkbox to ensure that the exchange object is in an
active state. If unchecked, the exchange object performs no actions. When the <Use in Linkage
Processing Only> checkbox is checked, the xChange object is only allowed during linkage processing
and not if the original EFI was triggered during the xChange process.
The following screenshot shows an exchange process enabled for MATERIAL. Any changes for the MATERIAL
master data are recorded in the exchange table and are transmitted to the client during the next transmit.
The Change Detection Field Selection tab lets you optimize the change detection process for a mobile
application. If a value change is detected for any fields within the group, the object identifier is written to the
exchange table, indicating that a change was made. If the <Active Flag> is not checked for a field, any value
changes made to that field are not detected and recorded to SAP during the exchange process. By default, all
fields are initially checked.
The Exchange Object by Application tree lists all application areas and the exchange objects linked to each
application area. Expand the tree by clicking on the arrows to the right of the application area to display the
exchange objects associated with it.
● Exchange Object Info: The <Exchange Object> field is read only and is the ID of the exchange object.
The <Exchange Object Description> is read only and is a brief description of the exchange object.
The <Exchange Object Handler> field is read only and is the name of the class handler from the
repository that is responsible for updating the exchange table.
● Exchange Object Field Selector: The <Field Catalog> column is comprised of non-editable rows of all
fields that are detected by the class handler when changes are made. These fields are grouped by the
technical table name of the SAP business object.
When the <Active Flag> checkbox is checked, either the table or a field within the table is active. Any
value change to the selected field is detected by the class handler. Note that if you check the Active Flag
checkbox on a table row, it selects all the rows within the table.
The <Short Description> is a read only field that contains a brief description of the table or of a field
withint the table.
● Selection Proposal: In a typical mobile application installation, you do not want to have all fields marked as
active for change detection. Rather, only the fields that are active on the odata mobile data object that are
brought down to the mobile device will also be active in the exchange object. Based on odata mobile data
object usage in the application, the selection proposal examines the active flags that are checked for an
exchange object's table fields and provides recommendations to the administrator on which fields should
be checked or unchecked.
The Change Detection Condition Filter tab lets you restrict change detection based on data content. For
exchange handlers to support this feature, define data filter conditions for which the underlying SAP business
object must qualify before the change detection process is triggered. The condition is defined at the table field
level and is in the SAP range table format.
● Exchange Object Info: The <Exchange Object> field is read only and is the ID of the exchange object.
The <Exchange Object Description> is read only and is a brief description of the exchange object.
The <Exchange Object Handler> field is read only and is the name of the class handler from the
repository that is responsible for updating the exchange table.
● Exception Settings: When the <Ignore Data Creation> checkbox is checked, newly created records
and data are not processed to the exchange table. When the <Ignore Data Deletion> checkbox is
checked, deleted records and data are not processed to the exchange table. When the <Ignore Data
Update> checkbox is checked, updated records and data are not processed to the exchange table.
● Defined Filters: Lists all the data filters supported by the class handlers.
● Rule Editor: The <Filter Name> is read only and is the name of the filter as defined by the class handler
developer in the class handler method. The <Reference Table Name> is read only and is the technical
name of the SAP database table field where the filter is applied as defined by the class handler developer.
The <Reference Field Name> is read only and is the technical name of the SAP database table field
where the filter is applied as defined by the class handler developer. The <Data Filter Rule Key> is an
internal technical key used by the framework at runtime.
Use the values in the Enter Range Value section to set the range. The <Sign> field is the value for the SAP
range table column SIGN. The <Option> field is the value for the SAP range table column OPTION. The
The following screen shows that any exchange detected for the exchange object NOTIFICATION will be
considered only if the notification is maintained in one of the roles defined in the NOTIF_CATG criteria.
● Application Logging Level: Defines the logging level for all framework components. Logging entries are
recorded in the SAP application log database under the object /syclo/. The logging levels are:
○ No logging
○ Abort
You can define security rule settings for the Mobile Integration Framework for SAP and mobile applications as
well.
All security checks are carried out by the Mobile Integration Framework at runtime, with checks performed at
the following levels:
● System
Application independent. Applies to all components built on the Mobile Integration Framework.
● Product
Security at the mobile application and product level
● Mobile Data Object Handler
Specific to a Mobile Data Object class handler
● OData Mobile Data Object Handler
Specific to an OData Mobile Data Object class handler
● User Role
Rules based on predefined user roles
You can define special security rules using user roles. These security rules can be assigned with system
indicators. These special security rules with system indicators are used to limit access to the ConfigPanel and
Administration & Monitoring tools. The following system indicators are available:
● System Administrator
If security rules are defined, only users with the required user role can have full access to the
Administration & Monitoring tool.
● System Administration – View Only
If security rules are defined, only users with the required user role can have read access to the
Administration & Monitoring tool.
● System Configurator
If security rules are defined, only users with the required user role can have full access to the ConfigPanel.
● System Configuration – View Only
If security rules are defined, only users with the required user role can have read access to the ConfigPanel.
Context
Code groups that belong together in terms of content are grouped in catalogs. These catalogs are identified by
the catalog type (a number or a letter). For example, in this way, you combine:
Use the CATALOGTYPE parameter group and the following parameters within the group to configure your
catalog types for notifications in SAP Shop Floor Manager:
● CatSubjectCoding: Default is 9
● CatTypeActivities: Default is A
● CatTypeCauses: Default is 5
● CatTypeDefects: Default is C
● CatTypeObjectParts: Default is B
● CatTypeTasks: Default is 2
● CatalogProfileOrder: Default is Equipment
The CATALOGTYPE parameters correspond to the rules found in the OData mobile data object
SPSV10_CATALOG_CODES. You can add a new data filter rule to your customer namespace, or change the
existing parameter-rule association to a new parameter-rule association.
Procedure
1. Using the ConfigPanel, navigate to Mobile Application Configuration Parameters tab . In the left
column, Defined Mobile Applications, select your application.
The Parameter List populates with a list of all parameters available for the application.
3. Make your desired parameter association changes, or change the value of a parameter to Z, a custom
activity catalog type.
4. Check the <Active> flag to ensure that the parameter is used by the mobile application. If desired, and if
not already checked, check the <No Runtime Change> box to ensure that the value of the parameter is
not overridden at runtime through synchronization processing.
5. Save your changes.
6. If you are creating a custom activity value type, navigate to OData Mobile Data Object Configuration
Data Filter Tab SPSV10_CATALOG_CODES Operation - READ Standard Filter CATALOG_TYPE .
7. Click the Change button. Add the new value. For information on working with rules, see Working with oData
MDO Filter Rules [page 54].
8. Save your changes.
Use parameters to configure Document types for Notification-related Document Link Object
Context
To provide a proper Notification attachment functionality, Document Link Object has to be configured.
Procedure
The Parameter List displays a list of all available parameters for the application. Relevant parameters are in
the DOCUMENT group.
2. From the DOCUMENT group, either scroll down to find the parameter or use the Search. Select the
parameter you want to configure, then select Change.
3. Make changes to the parameter association or change the value of a parameter to Z (a custom activity
catalog type).
4. Check the Active flag to ensure that the parameter is used by the mobile application. If it is not selected,
check the No Runtime Change box so that the parameter value is not overridden at runtime during
synchronization processing.
5. Save your changes.
7. Select the Change button. Add the new value for Object Type. For information on working with rules, see
Working with oData MDO Filter Rules [page 54].
9. Select the Change button. Add the new value for the Object link. For information on working with rules, see
Working with oData MDO Filter Rules [page 54]
11. Select the Change button. Add the new value for a new Object Type and relevant Object Link, select relevant
Document Types. For information on working with rules, see Working with oData MDO Filter Rules [page
54].
13. Select the Change button. Add the new value for a new Object Type and relevant Object Link, select relevant
Document Types. For information on working with rules, see Working with oData MDO Filter Rules [page
54].
14. Save your changes.
Each mobile user is connected to a back end SAP user. The back-end SAP user can be assigned one or more
roles. These roles grant their holders authorizations within the back end system. Through parameter
configuration, SAP provides a standard rule handler that performs a TCode authorization. SAP also provides
new globals that can turn on and off new features.
If a parameter is enabled to use a rule instead of a global, and the user role has an authorization to run a
specific transaction code, then that specific feature is enabled for that SAP user. If the user has the
The following features are available for you to enable or disable. Use the following subsection to learn how to
use the ConfigPanel to enable or disable a feature based on the authorization of the user.
Back-End Param
Component Functionality Category TCODE eter Comments
SHOP FLOOR Create work order Work Orders IW31 [Link] Includes opera
tions and suboper
MANAGER
ations
SHOP FLOOR Edit FLOC Functional Loca IL02 [Link] Includes adding
tion characteristics
MANAGER
(except local)
SAP ASSET MAN Edit equip Equipment IE02 [Link] Includes adding
AGER characteristics, in
stall, and disman
tle (except local)
SHOP FLOOR Equip attachment Attachments N/A [Link] See the Generic
upload Authorization
MANAGER
Check section in
this topic
SHOP FLOOR FLOC attachment Attachments N/A [Link] See the Generic
upload Authorization
MANAGER
Check section in
this topic
SHOP FLOOR Allow final confir- Confirmation N/A [Link] See the Generic
mation [Link] Authorization
MANAGER
Check section in
this topic
1. Using the ConfigPanel, navigate from the main screen to Mobile Application Configuration Parameters
tab . In the left column, Defined Mobile Applications, select your application.
The Parameter List table populates with a list of all globals available for the application.
2. Perform a search for the parameter you want to enable or disable as a feature by user role by using the
table in this topic to ensure that the parameter is available in the parameter framework for configuration.
Search for your parameter in the Parameter List using the Search box. All user authorization parameters
are found under the <Parameter Group> name of USER_AUTHORIZATIONS. Select your parameter and
click the Change button.
3. The rule /SMFND/CL_CORE_TCODE_CHECK_RU - TCode Authorization Check is already selected for you in
the <Rule ID> field. When you check the <Use Rule> checkbox, the rule is active.
4. Change the <Param. Scope> dropdown selection from Application to User.
5. If needed, select the appropriate <Dependent Parameter ID> from the dropdown list.
6. Check the <Active Flag> checkbox to ensure that your new parameter is active for the user role. Save
your changes.
The User Attributes tab in the Mobile Application Configuration page of the ConfigPanel allows you to maintain
multiple values for a selected attribute.
Context
There are three core configuration steps to implement mobile user attributes:
a. From the home page of the ConfigPanel, navigate to Mobile Application Settings Mobile
Application Configuration and select the User Attributes tab.
b. Click the Change button. Create your user attribute using the following fields. See the screenshot for
an example:
a. From the main page of the ConfigPanel, navigate to OData Mobile Data Configuration Data Filter
tab .
b. Select the OMDO filter to which you're adding the new user attribute from the user attributes defined
in the Mobile Application Configuration page in the ConfigPanel.
c. Choose your filter from the Defined Filters list. Click Change.
d. Assign your user attribute to the OMDO filter using a dynamic rule. The value is evaluated at runtime
based on the runtime mobile user attribute of the user.
e. Select Mobile User Attribute as the <Filter Rule Type>. See the following screenshot as an
example.
When you modify either an oData mobile data object or an exchange object, first make a copy of the object and
place it in the customer namespace.
Context
The following procedure provides information on making a copy of an oData mobile data object (OMDO) or
exchange object within SAP Mobile Add-On. In any of the procedures provided in this guide where an OMDO or
an exchange object is copied, refer to this procedure for instructions. When you copy either an OMDO or an
exchange object, you can roll back any changes you make to the application if necessary without changing the
original objects.
Once you copy an OMDO and modify the object, you may adjust the oData model definition to reference the
new OMDO. Similarly, when you copy and modify an exchange object, you may need to change the EFI trigger
assignment to the new exchange object. These procedures are covered separately.
Procedure
Note
Figures shown in this procedure are taken from the Exchange Object configuration page. Screens may
look different when configuring an oData mobile data object. For either, the ability to copy is provided.
A copy of the original object is created in the customer namespace. Now you can modify the object, with
the original object as a back-up for rollback purposes, if necessary.
Filter rules specify a single field within the database tables from which data is retrieved. Filter rules also specify
under which conditions records are included in the operation based on the value of the field.
Data filters are part of the configuration of an oMDO. If you make configuration changes to SAP Shop Floor
Manager, you may need to adjust the rules for one or more of the oMDO filters.
Many of the filters in SAP Shop Floor Manager either do not contain active rules or contain rules that you can
adjust. A filter only effects the synchronization behavior when it has one or more active rules.
The following procedure instructs you on how to adjust a filter using the ConfigPanel.
Many of the common configuration changes made for an SAP Shop Floor Manager implementation involve
modifying or adding one or more filter rules in an oData MDO.
Context
In SAP S/4HANA, each user is assigned a role based profile with authorization permissions on viewable data
and available activities. For example, a user working in one plant should not be able to view data for a different
plant. When business activities performed by a user are mobilized through the mobile application, the ability to
extend the same restrictions to the mobile application is necessary. Data filter rules provide the function to
restrict data access for mobile applications.
Use the following procedure to modify a data filter rule for an oMDO. The changes you make to the settings of a
given rule vary depending on your mobile application implementation requirements. Subsequent procedures in
the Configuration Guide refer to this procedure and provide detailed values and settings for filter rules involved
in the specific change.
Procedure
The current rule filter settings are displayed in the Rule Editor section. All existing rules for the filter are
displayed in the Rule List table.
Many of the fields in the rule editor become editable, and the buttons Add Row and Delete Row appear.
8. Set or modify any editable fields desired according to your mobile application needs.
9. Set the Active Flag to <True> for each added or edited field before saving changes. Inactive filter rules have
no effect on synchronization processing.
10. Click Save to apply your changes.
By default, the SAP Shop Floor Manager application determines the assignment of a notification associated
with the notification header. However, you can make minor configuration changes to support several other
assignment models for the notification object.
The following assignment types are supported for the notification object:
Perform the following steps to change the assignment type used in a deployment:
1. On the ConfigPanel home page, select OData Mobile Data Object Configuration. Make sure to select your
desired mobile application in the Mobile Application Filter field at the top of the page.
2. In the OData Mobile Data Object List select SPSV10_NOTIFICATION, and then the Data Filter tab.
3. Expand the Defined Filters list as follows; Operation - READ Data Distribution and click
NOTIF_ASSIGNMENT_TYPE. Click the Change button.
4. Set Low Value with the desired assignment type as defined by the assignment type model.
5. Save your changes.
A large set of records could affect performance on the SAP Shop Floor Manager client. Therefore, you can
employ more filtering based on the status of equipment.
By default, SAP Shop Floor Manager filters records through a user-dependent rule based on the planning plant
of the user.
To filter records on the status of equipment retrieved for the table stored on the SAP Shop Floor Manager
client, modify the SPSV10_EQUIPMENT OMDO. Specifically, in the following procedure, you will configure the
EQUI_INCL_SYS_STAT filter with a rule that specifies which status or statuses to include. After you configure
the rule, only the equipment records with the specified statuses are retrieved by the application for download
to the clients.
A common equipment status is INST. However, the INST status is only one example of many options. You can
configure other filters, either with this example, or in place of it.
For your given SAP Shop Floor Manager implementation, thoroughly review the equipment data stored in the
database before deciding which filter rules to configure. After your equipment review, create the appropriate
filters within the SPSV10_EQUIPMENT OMDO.
Prerequisites
● Know the status or statuses that you are filtering on for equipment synchronization, as they are used in the
procedure
● Have access to the ConfigPanel and permissions to change configuration settings
Context
Use the following procedure to create a filter rule for the OMDO, SPSV10_EQUIPMENT. Specifically, you are
adding a rule to the filter EQUI_INCL_SYST_STAT. After you add the filter rule, only the equipment records that
match the ones configured in the rule are downloaded to the SAP Shop Floor Manager client.
Procedure
Selecting an application filters the OData Mobile Data Object by Mobile App choices in the left panel with
only OMDOs available in your application.
3. View the new OMDO copy by selecting it in the OData Mobile Data Object by Mobile App list.
4. Select the Data Filter tab.
5. In the Defined Filters list, click the Operation - READ Standard Filter EQUI_INCL_USER_STAT node.
6. Add a rule to the filter with the following configuration settings:
○ Filter Rule Type: Static Value in Range Format
○ Sign: Inclusive
○ Option: =
○ Low Value: Equipment status to filter on
○ Active Flag: Checked
7. Repeat the previous step to include additional statuses in the filter.
8. Save your changes.
Results
When you finish the procedure, the equipment records downloaded by the SAP Shop Floor Manager
application are filtered to only include records with the status or statuses configured in the filter rules.
You may need to filter equipment according to additional criteria. Test that the status filters created during this
procedure are performing as expected before creating additional filters for the same data set. Regardless of
additional changes, test the synchronization of the equipment data thoroughly after you modify the
application.
The default implementation of SAP Shop Floor Manager includes the typical data values required by most
users and at most implementation. However, it is a common requirement that additional values are retrieved
and stored.
Prerequisites
● Determine and note the field values as well as any table values you want to add, as well as which tables the
desired fields reside in Mobile Add-On Integration Framework
● You must have access to the ConfigPanel and permissions to change configuration settings within it
Context
Use the following procedure to add new fields to OData mobile data objects.
Procedure
1. Navigate to ConfigPanel Home OData Mobile Data Object Configuration . Select the desired OMDO
from the list on the left of the current configuration page.
2. Click the Field Selection tab, then click the Change button.
Results
After completing the procedure, one or more new values are retrieved as part of the data for the object. The
new values are displayed, edited, searched on, or used in other manners on the mobile client.
In the example screenshot in the procedure, the OData mobile data object used is
SPSV10_PRODUCTION_ORDER. To make other OMDO configuration changes to the object, navigate to the
ConfigPanel home page, then click the OData Model Configuration link. On the left panel, find the corresponding
EntityType to make any additional configuration changes. In this procedure example, the entity type is
ProductionOrder. See Setting up an OData Mobile Data Object [page 59] for more information.
For OData troubleshooting information, see OData API in the SAP Cloud Platform documentation.
The following table lists the OData features that SAP Mobile Add-On supports.
$inlinecount Supported
$skiptoken Supported
$format Supported
Navigation Supported
Tombstone Supported
$batch Supported
Deep insert Supported via single post operation and through $batch re
quest using content ID referencing
$filter Details
● Supported:
○ bool substringof(string p0, string p1)
● Not Supported:
○ string trim(string p0)
○ string concat(string p0, string p1)
○ int length(string p0)
○ int indexof(string p0, string p1)
○ string replace(string p0, string find, string replace)
○ bool endswith(string p0, string p1)
○ bool startswith(string p0, string p1)
○ string toupper(string p0)
○ string substring(string p0, int pos)
○ string substring(string p0, int pos, int length)
○ string tolower(string p0)
Note
For related constraints, see SAP Note 1830712 .
You can assign SAP system aliases to a service. With the assignment, an OData request from an SAP Gateway
consumer can be routed to the corresponding back end service.
Context
Assign OData services to the SAP Shop Floor Manager application using the Service Assignments tab.
Build a hierarchy between assigned services using Composition Settings. To utilize OData entities from a
different service such as the Crew Management and Field Operations Worker component service, add the
Procedure
1. Ensure that your mobile application is selected in the Mobile Application Filter field at the top of the page.
2. Expand the Mobile Application List in the left pane and select your mobile object.
Your chosen mobile application OData service assignment details are displayed in the main window on the
Service Assignments tab.
3. Click the Change button to change the existing mobile service assignment details or to add a new mobile
service assignment.
4. To add a new mobile service assignment, click the Assign OData Service button.
a. Select an OData Version, if there is more than one to choose from, from the dropdown menu.
a. Select an OData Service, or system alias, from the dropdown menu.
Next Steps
Prerequisites
If you are setting up a new OData mobile data object, or changing an OMDO, read and perform the following
procedures before performing this procedure:
● Setting the OData Mobile Data Object Service Assignment [page 61]
Procedure
1. Navigate to and click the Mobile Application Integration Framework Configuration Home OData Mobile
Data Object Configuration link.
The OMDO handler will provide the data source for the entity record.
7. Enter a short Description of your new OData mobile data object.
8. Choose one of two settings for the Process Flow in the Read Request Process Flow section:
○ Standard Flow Using Key List
Next Steps
An OData model gives detailed information about each object in an OData feed. You can define a new data
model in your application to suit your requirements based on the data you want expose at runtime.
Prerequisites
● Setting the OData Mobile Data Object Service Assignment [page 61]
● Setting the OData Mobile Data Object Configuration [page 63]
Context
Entity Sets are used to group instances of an entity type together with instances of any type that are derived
from this particular entity type. You can access the OData entity details from the ConfigPanel home page by
choosing OData Model Configuration.
You can define properties for entity types on the Property List tab. Properties define the characteristics of data
that an entity type instance contains at runtime.
Navigation properties describe the association relationship between two entities. The navigation property is
tied to an association, and it allows the navigation from one end of the entity type, which declares the
Finally, you can set the bind structure conversion exits and the Media flag for entity type on the Additional
Setting tab.
Note
Optional steps are included to explain the required fields when creating a new OData model. These fields
are grayed out when you are working with a copied OData model and you can ignore them in the procedure.
Procedure
1. Navigate to and click the Mobile Application Integration Framework Configuration OData Model
Configuration link.
Note that you cannot share models between OData services. Each service has its own model.
4. If you are creating a new OData model, click on Create button on the top and type an entity type name in
the field. The entity type name represents the structure or a single record.
5. Select an OMDO ID from the drop-down list. The OMDO ID is the object that is providing the data for the
record.
6. Select an OMDO Entity Type from the drop-down list. The OMDO entity type is the source that provides
information to the OData model. When a service request for the entity type occurs, the OData model
invokes the selected OMDO ID and the related handler method.
7. Type an EntitySet Name into the field. While an entity type describes a data structure, an entity set
contains the instances of the given structure. Therefore, a best practice for an entityset name is to create a
plural of an entity type name. For example, if an entity type name is Test, the entityset name will be Tests.
8. Check any of the following checkboxes to enable additional OData features. Note that some may require
additional configuration on other tabs or links.
○ Createable: Similar to a POST request in REST
10. To add a new property to the entity type, click the Add button.
a. Type the property name into the <Property Name> field.
b. Select an oMDO Field Name from the dropdown list.
c. Select the appropriate EDM Type (Entity Data Model) from the dropdown list.
d. Check the Key column for Key fields.
e. Define the attributes of the new property depending on the scope of the entity type.
If you use the Datetime Edm Type and its related properties as an optional field, set the attribute Nullable to
true.
11. Click the Association & Set List tab.
Associations themselves are freestanding. Specify on top of the associations, which of the entities
participating in the relationship can navigate over the association to the other entity using the Referential
Constraints tab.
12. Click the Add Association button to add a new association. Associations define a peer-to-peer relationship
between participating entity types, and can support different multiplicities at both ends.
a. Type a name for your new association in the Association Name field.
Your Association can be either internal or external when adding a new association; by default the
current entity will be the principle entity. If you want to add an external association where the current
entity is treated as dependent entity, select the External Association checkbox.
b. Select the dependent entity from the Dependent Entity Type drop-down menu for internal association,
whereas select the Principle Entity Type Id from the drop-down for external association.
c. Choose the Principle Cardinality and the Dependent Cardinality. Both use the following cardinality
rules. Note that many-to-many relations are not supported in SAP Shop Floor Manager
○ 0..1: Only one instance occurs; zero is also allowed
○ 1: One-to-one relations. Exactly one instance occurs
○ 0..n: Zero-to-many relations. Zero or more instances occur
○ 1..n: One-to-many relations. One or more instances occur
d. Select the Principle/Dependent OnDelete Cascade checkbox, if you want to delete an associated
collection when a principle or related parent entity got deleted from the mobile device. This feature
only works with local objects.
e. Type the name of your association set in the Association Set Name field under Association Set.
13. Click the Referential Constraints tab to add or change a referential constraint.
You have to match the key properties of the principle entity type with the properties from the dependent
entity type that correlates to the key property of the principle type. Populate all key properties from the
principle entity type.
The navigation property is tied to an association, and it allows the navigation from one end of the entity
type that declares the navigation property to the other related end.
Note
If you add a new navigation entity, first add a new association for it through the Association & Set List.
Set the association cardinality for both principle and dependent entities.
15. Click the Add Navigation Property to add a new navigation property.
You can create a navigation property for both principle and dependent entity type using the same
association so that link will be created in both directions.
The Dependent OMDO ID and Dependent Tech Entity Type cells are populated based on which
association entity you choose.
d. Repeat these substeps to create the navigation property on the remaining principle or dependent
object.
16. Click the Additional Setting tab.
a. Select the Media Flag checkbox for media-related entity types to trigger the download of media
content on the entity set collection.
b. Select the Enable Structure Conversion Exit checkbox to allow the SAP Shop Floor Manager application
to access the OData channel. The OData channel delegates handling of conversion exits, currency,
currency amounts, units of measurement, and unit amount conversions to the SAP Gateway
framework.
Results
Once the model is fully defined, when a client makes an HTTP request, it is calling for the metadata for an
OData service. The SAP Gateway returns an XML string to the client, which is also reflected in the ConfigPanel.
A data distribution model defines how and what back end data are downloaded to the mobile devices.
Data distribution models consider various factors when determining what backend data should be downloaded
to the mobile client and to the mobile user. Some common criteria are:
For the initial synchronization from the mobile device to the back-end system, the first two bullet points are
considered when determining what data should be downloaded to the mobile device and for the requesting
user. For subsequent delta synchronizations from the mobile device to the back-end system, all bullet points
are considered when determining what data should be downloaded to the mobile device for the requesting
user.
The following data distribution models are supported for the SAP Shop Floor Manager application:
● OMDO Filters
Object data collection entirely depends on OMDO filter conditions.
● Dependency Queue
Object data collection entirely depends on Dependency Queue objects, and no filter conditions are applied
for the fetch criteria.
● Dependency Queue + OMDO DOF Filters
Object data collection is based on dependency queue objects, and the OMDO DOF filters are applied for the
result set.
● Other (Custom BAdI)
You can implement your own distribution logic using a BAdI.
To change the data distribution model for a particular OMDO object, complete the steps below:
1. On the ConfigPanel home page, choose OData Mobile Data Object Configuration.
Make sure you select your desired mobile application in the Mobile Application Filter field at the top of the
page.
2. From the OData Mobile Data Object List select the desired OMDO object, such as SPSV10_MATERIAL, and
then click on the Data Filter tab.
3. Expand the Defined Filters list under Operation - READ Data Distribution
OBJECT_DISTRIBUTION_MODE . Choose the Change button from the menu.
4. Set the distribution model.
5. Save your changes.
By default, the SAP Shop Floor Manager application determines the assignment of production orders and
notifications using the production orderID at header level.
ORDER_CATG Data Distribution, Optional See specific rule Restricts production order distribu
for value tion based on production order cate
gory. For productionorders, it should
be value 1.0.
DOC_GOS_RELTYPE Standard Filter, Optional Data Segment, Op Determines whether the GOS at
tional tachment is supported based on a
GOS relationship.
DMS_DOC_TYPE Standard Filter, Optional Data Segment, Op Determines whether the DMS at
tional tachment is supported based on the
DMS document type.
DOC_LINK_OBJ Standard Filter, Optional Data Segment, Op Determines whether the DMS at
tional tachment is supported based on the
linked SAP object.
This section describes the various troubleshooting activities that you can perform in error situations, or the
app users can perform on a regular basis to ensure the smooth running of the mobile application. It is also
explains how to monitor the different components of SAP Gateway, how to use the logs, and how to carry out
maintenance activities.
You can use the SAP Gateway Client (transaction code: /IWFND/GW_CLIENT) to test your OData service
provider without an OData consumer, such as the SAP Shop Floor Manager mobile client. This tool is especially
useful to test your OData service from the back end to identify service-related issues before a service is used by
the mobile application.
For more information about how to work with the SAP Gateway Client, see SAP Gateway Client in the SAP
Gateway Technical Operations Guide.
Error logs provide detailed context information about errors that have occurred at runtime, enabling you to
perform root cause analysis, as well as reproducing and correcting errors.
You can launch the error log with transaction /IWFND/ERROR_LOG in Gateway Hub systems. Launch the error
log with transaction /IWBEP/ERROR_LOG in your back-end system.
The SAP Gateway error logs reveal basic details about errors and show errors from all users for a given client.
Business logic errors are often displayed in this error log due to improper business logic. Other errors displayed
include the HTTP code to indicate the type of error.
Note that based on the security level setting, advanced details or the replay function may be hidden or
disabled. Note also that these error logs will not show generic authorization errors if users fail to properly
authenticate.
You can navigate to different sections from the Error Context area as shown above. Choose Replay to reproduce
and correct errors. Choose from the following two replay options:
Use option SAP Gateway Client to reproduce runtime situations that led to a particular error without accessing
the application from the actual mobile client, and to simulate a service at runtime to identify and resolve
potential issues.
For more information about how to configure the error log, see Configuration Settings for the Error Log in the
SAP Gateway Technical Operations Guide.
You can use the SAP Gateway Statistics (transaction code: /IWFND/STATS) to display the request statistics
and aggregated statistics. Each successful OData request has an entry in the statistics records, which is kept
for 7 days by default, however, you can extend the period to 30 days. Request statistics can be aggregated, in
which case they are kept for 90 days by default, however, you can extend the period to 365 days.
SAP Gateway Statistics aggregates the entries by various entities, for example, client, namespace, service
name and version. With the /IWFND/STATS transaction you can verify details, such as processing time,
response size by entity, and other statistics about the complete request.
The SAP Gateway provides tracing tools (transaction code: /IWFND/TRACES) to trace on a particular user for
both performance and payload.
Performance trace enables you to monitor performance at service call level for both the SAP Business Suite
and the SAP Gateway. Payload trace enables you to monitor the service calls with request and response data,
and to replay and simulate the service calls without accessing the application from the mobile client.
Traces display detailed request and response data coming into the SAP Gateway. Traces are active for only a
short time, and are purged on a regular basis.
For information about how to configure and activate the payload trace tool, see Tracing Tools: Configuration in
the SAP Gateway Technical Operations Guide.
Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:
● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your
agreements with SAP) to this:
● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.
● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.
● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such
links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this
information.
Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax
and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of
example code unless damages have been caused by SAP's gross negligence or willful misconduct.
Gender-Related Language
We try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.
SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.