SAP Service and AssetManagerConfigurationGuide
SAP Service and AssetManagerConfigurationGuide
14 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
14.1 SAP Gateway Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
14.2 SAP Gateway Error Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
14.3 SAP Gateway Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
14.4 SAP Gateway Tracing Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
Before you begin reading this guide, be sure that you have the latest version. Find the latest version at https://
[Link]/docs/SAP_SERVICE_ASSET_MANAGER.
The following table provides an overview of the most important document changes.
Note
This guide only covers setting up and enabling the SAP Service and Asset Manager application on a
Windows platform.
The SAP Service and Asset 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 setup of SAP.
Use the SAP Service and Asset Manager Configuration Guide along with appropriate SAP documentation.
SAP Service and Asset Manager is a mobile solution for managing work orders, notifications, condition
monitoring, and material consumption. The application also performs time management and failure analysis.
Regardless of connectivity, SAP Service and Asset Manager allows remote employees to access, complete,
and manage their assigned work orders and notifications through their devices. With SAP Service and
Asset Manager, they have SAP back end data readily available including task lists, repair histories, reference
documents, and geospatial data such as addresses and maps. 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.
SAP Service and Asset Manager comes packaged with a mobile add-on for SAP ERP and a mobile add-on for
SAP S/4HANA. They offer tight integration and easier deployment without interference to or from your existing
SAP system customizations or standard SAP objects. They provide you with full configuration, administration,
and monitoring features that allow you to manage the SAP Service and Asset Manager application from within
your SAP system infrastructure.
SAP Service and Asset Manager supports the following back-end systems:
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
Service and Asset Manager 1911 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 Service and Asset Manager is a mobile solution for managing work orders, notifications, condition
monitoring, and material consumption. The application also performs time management and failure analysis.
Regardless of connectivity, SAP Service and Asset Manager allows remote employees to access, complete,
and manage their assigned work orders and notifications through their mobile devices. With SAP Service and
Asset Manager, they have SAP back end data readily available including task lists, repair histories, reference
documents, and geospatial data such as addresses and maps. 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.
SAP Service and Asset Manager comes packaged with a mobile add-on for SAP ERP and a mobile add-on for
SAP S/4HANA. They offer tight integration and easier deployment without interference to or from your existing
SAP system customizations or standard SAP objects. They provide you with full configuration, administration,
and monitoring features that allow you to manage the SAP Service and Asset Manager application from within
your SAP system infrastructure.
The main features and functions available in SAP Service and Asset Manager include the following.
SAP Service and Asset Manager supports the following standard SAP Plant Maintenance Work order
functionalities on the mobile device:
The following data related to maintenance execution can be captured from the mobile device:
Time Management
Maintenance technicians can use SAP Service and Asset Manager to trace their time efficiently and accurately
by entering the timesheet and the attendance records from the mobile device.
Single Sign-On (SSO) allows the user to log into the SAP Service and Asset 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 Service and Asset Manager supports viewing of leading 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:
• Work orders
• Notifications
• Equipment
• Functional locations
Inspection rounds with routing is an optional feature available as the SAP Service and Asset Manager Field
Operations Worker (FOW) component. FOW supports:
Route and stop definition is implemented via the standard work order inspection round functionality.
SAP Service and Asset Manager supports work crew management. This feature supports:
Crew management is an optional feature available as the SAP Service and Asset Manager Crew Management
component.
SAP Service and Asset Manager supports the industry solution for utilities meter management. The following
standard features are supported:
SAP Service and Asset Manager supports customer service. This feature supports:
Asset Central links production systems and assets with manufacturing and maintenance business processes to
reduce operational and maintenance costs and increase asset uptime. Using Asset Central, you can use PdMS,
or Predictive Maintenance and Service equipment indicators that allow you to identify the health status of your
equipment.
SAP Service and Asset Manager uses the SAP back end and specific SAP ERP transaction codes to help
configure the application.
The SAP Mobile Add-On provides integration services for SAP Service and Asset 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 Service and Asset 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.
Note
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 following areas are used in configuring general information for the application:
The Mobile Application Configuration page allows you to configure general settings for the entire mobile
application.
• General
• Mobile Status Setting
• Conversion Exit Setting (not used in SAP Service and Asset Manager)
• System Components (not used in SAP Service and Asset Manager)
• Parameters
• Client Globals (not used in SAP Service and Asset Manager)
• User Attributes (not used in SAP Service and Asset Manager)
Application Persona
• Features
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 Service
and Asset 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
the xChange process is also disabled. The <Effective Date> and <Time> fields flag when the change
takes effect.
• xChange Setting: When the <Disable Change Detection> box is checked, the change detection
process, or xchange process, for the application is completely disabled.
• Inbound Transaction Management: Not used in the SAP Service and Asset Manager application.
• Multi Backend Setting: When checked, enables a specific mobile application to connect to multiple SAP
systems, consisting of one host server and one or more satellite servers.
• System Role: Dropdown menu where you can select either Host or Satellite.
A Host system is the connection between SAP and the SAP Service and Asset Manager application in the
SAP Business Technology Platform. The host server provides the logic to the application and functions as
the bridge to the satellite server or servers. There can only be one host server per system.
Use the Mobile Status Setting tab to map the available mobile statuses that an oData mobile data object
(OMDO) supports on the client side. If a user status also exists for the same object type, you can link it to the
mobile status and the system status through this 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.
• Mobile Status Mapping: Use the <Add Status> and <Delete Status> buttons to create and delete
mobile status mappings. Fill out the <Object Type> with the specific object in the mobile application, for
example, <Notification>. The <Mobile Status> is the status defined by the mobile application. The
<Label on Mobile> is not used. The <User Status> is an SAP status code as defined in SAP. Note that
the status codes are language independent codes.
If the <Initial Status> checkbox is selected, the mobile status is displayed by default when you
download the object to the mobile device. To skip a specific mobile status update from a mobile device, use
the <Skip Update> checkbox corresponding to the mobile status object.
Use the Mobile Status Alias List table to define language-specific mobile status aliases.
In the following example screen, the highlighted row in the mapping table indicates that if a user sets a work
order to completed, the application sets the work order system status to I0045 in SAP.
If there is a user status specified but no status profile when the mobile user sets the mobile status, the app sets
that user status for the object, disregarding the status profile of that object.
If there is a user status and status profile specified when the mobile user sets the mobile status, the app sets
that user status if the object uses that status profile.
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.
• Application Parameters: Use the <Add> and <Delete> buttons to create and delete parameters.
• Parameter Detail: The <Parameter Group> is the group to which the parameter belongs. Groups are
how you organize parameters. References to a parameter include both the group name and the parameter
name. The <Parameter Name> is the unique name of the parameter.
The <Parameter Value> is the currently configured value of the parameter. References to the
parameter return the configured value. Use the <Language Specific Value> checkbox to select which
parameters you wish to be language dependent. The checkbox and the corresponding Language Specific
Values tab are only active after you have clicked the Change button. Note that the language available in the
Note
For information on setting user parameters, see the following security guides, depending on your
back end system:
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.
The persona selected determines the data that is downloaded to the mobile client.
Application Personas
Features Tab
Switchable features allow you to configure various components into features. Feature assignment determines
the data that is downloaded to the mobile client.
Switchable Features
Check or uncheck a feature from the feature list to enable or disable it.
The Component Assignments page allows you to configure persona and feature assignments.
Use the Mobile Application Filter field to select your application. Then, click the application hyperlink in the
Search Results table.
Use the Apply Filters section to filter for a specific persona or specific features. In the following example, we've
filtered for all features that belong to the MAINTENANCE_TECHNICIAN persona.
The Feature Assignment section shows you the filtered results. Use the drop-down menu to further filter
your selections. For example, we've chosen to display only active, or selected features for the maintenance
technician persona.
The Switchable Features tab allows you to configure OMDOs required for each feature. During initial and delta
syncs, the mobile client only downloads data from the assigned OMDOs.
Use the Apply Filters section to filter for a specific OMDO or feature ID.
The Assignment List section shows you which OMDOs are assigned and active (or not active) with a feature.
Note
Don’t select OMDOs that belong to the online service (ex: /MERP/SAP_ONLINE_LOOKUP_EXT_<version>).
These online service entities might not exist in the base service (/MERP/
SAP_ASSET_MANAGER_<version>).
A geographic information system (GIS) integrates hardware, software, and data for capturing, managing,
analyzing, and displaying all forms of geographically referenced information.
Note
GIS is enabled by default. See the Geospatial Service Definitions - GEF [page 27] topic if you are using GEF
(SAP Geographical Enablement Framework).
Geospatial data plays an important part in the daily operations of many organizations. By adding geospatial
data to the technical data of an asset, you get a full picture of that asset.
• General Data
• Object Type Assignment
• Parameter Settings
• Data Rules
Basic Data
• Service ID: Required field. Name of the geospatial service ID, limited to 40 characters, with namespace
protection. Use the Y or Z namespace.
• Description: Description of the geospatial service
• Mobile Application: Mobile application of the geospatial service. Every geospatial service is assigned to a
specific mobile application.
Note
The information in this field is used in the Target Host field in the Creating and Configuring an RFC
Destination for Offline Maps [page 183] procedure.
Activation
• Active Flag Check the checkbox to activate the GIS query service
Use the Object Type Assignment tab to define what type of SAP objects are assigned to the geospatial service.
You can define different geospatial services for different SAP object types.
For example, you can map equipment with polygon geospatial data to one geospatial feature layer. You can then
map equipment with point geospatial data to a different geospatial feature layer.
Use the Parameter Settings tab to define parameter settings for the service provider handler. The service
provider handler can declare the list of parameters that might require input. If parameters are declared, they
are displayed on this tab, and you can enter values for them.
Use the Data Rules tab to define data rules. A data rule is used to transform input data to the service provider
handler, before calling the geospatial service. For example, to dynamically assign values of object type, object
group, and object group 1 to input data, use a data rule. Using a data rule influences which geospatial service is
assigned to an input object.
The SAP Geographical Enablement Framework (GEF) enables the augmentation of business data with spatial
attributes for SAP S/4HANA applications. The framework allows SAP data to be used in GIS-based geo-
processing operations.
Note
GIS is enabled by default. See the Geospatial Service Definitions - GIS [page 22] topic if you’re using GIS
(Geographical Information System).
GEF reduces, and in some cases, eliminates the need for complex synchronization between SAP and GIS
systems. Business data can be combined with engineering data in a single map view independent of the user
working with SAP tools or GIS tools, decreasing TCO, increasing the value of business data, and simplifying
user interaction.
The framework provides an embeddable map-based UI for SAP S/4HANA applications to quickly geo-enable
their business objects and support geospatial processes. It also exposes the geometries and attributes of
geo-enabled SAP business objects as feature classes to be consumed via standard GIS tools.
• General Data
• Object Type Assignment
• Parameter Settings
• Data Rules
As GEF is integrated directly to SAP S/4HANA systems, there’s no need to call REST APIs outside of SAP
S/4HANA. All information and coordinates are already stored as part of the system.
Basic Data
• Service ID: Required field. Name of the geospatial service ID, limited to 40 characters, with namespace
protection. Use the Y or Z namespace.
• Description: Description of the geospatial service
• Mobile Application: Mobile application of the geospatial service. Every geospatial service is assigned to a
specific mobile application.
Note
Activation
• Active Flag Check the checkbox to activate the GEF query service
Use the Object Type Assignment tab to define what type of SAP objects are assigned to the geospatial service.
You can define different geospatial services for different SAP object types.
For example, you can map equipment with polygon geospatial data to one geospatial feature layer. You can then
map equipment with point geospatial data to a different geospatial feature layer.
Assignment Info
• Logical System: Logical system of the SAP object. A logical system is required to properly identify the
SAP object if the mobile add-on aggregates data from different back-end systems. You can configure the
following fields on the
• Object Type: Type of the object as it is identified in the mobile add-on. For example, the standard object
type IEQ is used to identify the Equipment object.
• Object Group: Optional setting used to further group the objects in the same object type.
• Active: When the Active checkbox is marked, the assignment is active.
• Object Group 1: Optional setting used to further group objects of the same object type and object group.
Use the Parameter Settings tab to define parameter settings for the service provider handler. The service
provider handler can declare the list of parameters that might require input. If parameters are declared, they’re
displayed on this tab, and you can enter values for them.
The EAM Scenario parameter data mines the GEF scenario object. For each scenario, there’s a corresponding
business object:
You can assign different business objects for your system needs.
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.
• Do not define the Gateway OData technical model using the Gateway Service Builder. The
model is determined and generated dynamically by the generic model provider class /MFND/
CL_CORE_ODATA_V2_MPC based on the model configuration settings defined in the ConfigPanel.
• The generic data provider class /MFND/CL_CORE_ODATA_V2_DPC doesn’t provide the required business
logic for the Gateway OData technical service. Business logic is provided by OMDOs. Assign every OData
business request to the service to an OMDO. The assigned OMDO performs the necessary business logic
for the business request.
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.
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.
The following attributes are available for the Entity Type definition:
• 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 Service and Asset Manager
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
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
for the represented business object, including all aspects of related operations such as object creation, update,
deletion, or read and downloading. The OMDO also supports configuration such as data distribution rules for
data download.
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.
The Technical Model Info tab is a display only tab. This tab displays the technical entity model supported by the
OMDO handler.
• Technical Entity Type: Technical entity type that the OMDO handler supports
• Lead Entity: Indicates whether a technical entity is the lead entity type supported by the OMDO handler.
The lead entity type represents the header record of a business object. An OMDO operates on a business
object level. For an OMDO CREATE operation, a create request (POST request) for the lead entity type is
required. If the lead entity already exists, a CREATE request (POST request) for nonlead entity types are
considered as OMDO UPDATE operations.
• Reference Structure: Data dictionary structure of the technical entity type
• Field Name: Field name from the data dictionary structure
• Field Description: Field description
• Data Type: Field data type
• Conversion Exit: Assigned conversion exit for the field
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 Service and Asset Manager downloads detailed information for equipment and functional
locations used in work orders assigned to a technician. To fulfill this requirement, read requests for work order
assignments occur first, and equipment and functional locations are set up as dependent objects for the work
order OMDO.
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.
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.
• Dependent Object Key Field Name: Field name of the dependent technical entity type that receives the
value from the source technical entity type field
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.
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 Service
and Asset Manager, communicates with SAP and the object tables contained within SAP
• Exchange Object Configuration: Change detection rules for SAP data objects, such as leading data and
transaction data, defined for each mobile application
• EFI Assignment: Enhancement framework implementation trigger assigned to exchange objects
Note
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 first 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.
Assignment Tab
• EFI Information fields: The EFI information fields at the top of the Assignment tab, like <EFI Type> and
<EFI Event Handler>, are taken from information in the General tab and are read only.
• EFI Assignment List: Table that displays the plug-ins that are assigned to a specific include file. All column
information is replicated in the Assignment Detail section directly below the table.
• Mobile Application: Read-only name of the specific mobile application
• Exchange Object: Name of the exchange object to which the EFI include file is assigned
• Exchange Object Description: Read-only description of the exchange object
• Exchange Object Handler: Read-only name of the class handler from the repository responsible for
updating the exchange table
• Active Flag: When checked, the exchange object is in an active state. If unchecked, the EFI isn’t linked to
the assigned OMDO.
• Use in Linkage Processing Only: When checked, the xChange object is only allowed during linkage
processing. If not checked, the original EFI is triggered during xChange processing.
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
• Push 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 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.
See the following screenshot for an example of the enabled exchange object MATERIAL, where the properties
of the object are captured and recorded in the exchange table. The properties that trigger the exchange are
defined on this Change Detection Condition Filter tab, as seen in the checked <Active Flags>:
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.
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.
Push scenarios define the trigger conditions, type of data, the mobile users receiving the data, and the users
for the data.
A mobile client typically synchronizes with the SAP system by initiating a synchronization request to download
the latest application data from the SAP system. Some mobile applications require the SAP system to send
application data or push notifications to the client when certain trigger conditions are met. If these trigger
conditions are not present, the mobile client does not initiate the synchronization request.
You define trigger conditions through the creation of push scenario definitions. Use the tabs found in the Push
Scenario Definition page to configure a push scenario. The Push Scenario Definition page contains the following
tabs:
• General Data
• Event Setting
• Outbound Trigger
• Subscription Settings
You can define the following attributes in the General Data tab:
• Basic Data section: Enter the ID of the push scenario in the required <Scenario ID> field, which is
limited to 40 characters with namespace protection. Use either a Y or a Z namespace. Ensure that the ID is
unique in the SAP system. Enter the name of the mobile application in the <Mobile Application> field,
limited to 40 characters. Give an optional <Alias> to the push scenario. Multiple push scenarios can share
the same alias, to allow central processing on the client side.
• Source Setting section: The <Source Type> defines how to trigger the push scenario. Two options are
supported:
• xChange Object: The push scenario is triggered when qualifying data is changed in the SAP system
and change conditions defined in the xChange object are detected.
• Client on Demand Request: The push scenario is triggered based on a request from the mobile client.
No data change in the SAP system is required. The client on demand request is not available for OData
based mobile applications.
The <Source Object> applies to the source type of the xChange object. The xChange object determines
the data change trigger for the push scenario. The <Source Handler> is the xChange handler assigned
to your selected xChange object.
You can define the following attributes in the Event Setting tab:
• Background Event Setting Detail setting: If the Disable Background Event Trigger checkbox is not
checked, a background event is raised during push processing.
• Standard Event Setting: The <Event ID> is the background event ID that is raised. The <Event
Parameter> is the background event parameter.
• Rule Based Event Setting: The <Push Event Rule> is a routine that generates a dynamically formatted
event ID and parameter based on supported runtime variables.
• qRFC Setting Detail: If the Enable qRFC Processing checkbox is checked, push processing is handled in
the background as a qRFC call.
Outbound triggers handle interfacing with external systems. You can assign multiple outbound triggers to a
push scenario. Assigned outbound triggers are invoked at the end of push processing, based on the assigned
sequence.
To allow an on-demand subscription based push request from the mobile client, define the subscription setting
in the Subscription Settings tab. Subscriptions allow the mobile client to trigger a push process instead of
a traditional trigger by the back end SAP system update. OData based mobile applications do not support
subscription-based on-demand push configuration.
• Allow Subscription: Check to enable subscription-based push processing for the push scenario
• Subscription Agent ID: Displays the subscription agent assigned to handle the subscription request
Outbound triggers allow a mobile application to interface with external systems such as the SAP Business
Technology Platform.
You can integrate outbound triggers into one of the following mobile application processes:
• Push processing
• OData mobile data object processing
An outbound trigger can support only one of the two available processes. The process is determined by the
outbound trigger handler. An outbound trigger handler can support any of the interface technologies, such as
HTTP triggers, file triggers, and web service triggers.
• General Data
You can define the following attributes in the General Data tab:
Basic Data
• Outbound Trigger ID: Required field. Unique ID of the outbound trigger in the Y or Z namespace, limited to
40 characters.
• Outbound Trigger Description: Short description of the outbound trigger
• Mobile Application: Select your mobile application. The outbound trigger configuration detail is defined
for the individual mobile application.
Retry Setting
• Allow Retry: If checked, the outbound trigger is allowed to rerun
• Maximum Number of Retry: Set the maximum number of times the outbound trigger can rerun
• Retry Wait Period (Seconds): Set the minimum wait time between output trigger retries
Activation
If the Active Flag checkbox is not checked, the outbound trigger is not enabled.
Parameters Tab
An outbound trigger handler can declare special purpose parameters. If parameters are declared, they are
displayed in the Parameters tab. You can declare any number of parameters. A parameter can be a single field
parameter or a structured record.
• 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
• Error
• Warning
• Info
• Debug
• Trace
• Enqueue Wait Time (Sec): The Enqueue Wait Time parameter controls the number of seconds the
underlying component should continue to try to access a locked SAP object in intervals of 1 second during
an update by a mobile device. The update process aborts if accessing the locked object is still unsuccessful
after the wait time.
• Internal Conversion Exit Active: When checked, the framework runtime data manager performs a
standard SAP external-to-internal format conversion exit for all inbound BAPI parameters. The option
is enabled by default. An application developer should only change this setting as it has a direct impact to
the SAP Service and Asset Manager application.
• External Conversion Exit Active: When enabled, the framework runtime data manager performs standard
SAP internal-to-external format conversion exit for all outbound BAPI parameters. This option is enabled
by default. An application developer should only change this setting as it has a direct impact to the SAP
Service and Asset Manager application.
• Range Parameter Check Active: When enabled, the framework runtime data manager performs checks
on all SAP range parameters of inbound BAPI parameters. The SAP range parameter has the structure of
SIGN, OPTION, LOW and HIGH. If SIGN and OPTION are not specified, a check routine sets SIGN to I and
OTPION to EQ. This option is enabled by default. An application developer should only change this setting
as it has a direct impact to the SAP Service and Asset Manager application.
• Collection Mode: Collection mode determines how system statistic records are written to the database.
Two modes are supported currently: Synchronously and Asynchronously. When you select Synchronously,
the statistics record is written to the database in real-time during BAPI calls. However, selecting this option
incurs a performance penalty. Selecting Asynchronously means that statistics are collected in-memory
and written asynchronously to the database at the end of the BAPI call.
• Statistic Collection Active: When enabled, the framework records all runtime statistics associated with
the BAPI calls between the middleware server and SAP. This collection provides data for the KPI statistics
collections found in the Administration portal. An application developer should only change this setting as
it has a direct impact to the SAP Service and Asset Manager application.
• Created By, Creation Time Stamp, Last Changed By, Changed Time Stamp: The user ID and time
stamps are automatically logged when a record is created or changed.
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.
Prerequisites
Note
For EPD visualization integration with the SAP Service and Asset Manager app to work properly, both the
EPD and SAP Service and Asset Manager tenants must be set up in the same SAP BTP region.
To preconfigure the SAP Product Model Viewer (PMV), refer to the Overview chapter of the SAP Product Model
Viewer Administration Guide.
To create a visualization destination within the SAP Service and Asset Manager app to connect to the PMV
account, refer to the Configure the Mobile Application chapter of the SAP Product Model Viewer Administration
Guide.
Context
EPD visualization in the SAP Service and Asset Manager is available by enabling the feature in the configuration
panel. The feature is only available for the Maintenance Technician and Field Service Technician personas.
1. To enable or disable the feature, check or uncheck the Active Flag box and save.
Note
2. To use EPD visualization in the SAP Service and Asset Manager app,maintain the application parameters
in the ConfigPanel. Navigate to Application Configuration <select Mobile Application> Parameters
tab .
3. Depending on which object is configured in the EPD, choose an option:
• To maintain usage ID: Param. Value: Usage ID for equipment/functional location/material from EPD
(example values: As-Maintained/As-Installed/As-Designed)
Persona and feature assignments determine the data downloaded to the mobile client application.
The entity types below are introduced in SAP Service and Asset Manager to return persona- and feature-
related configurations to the mobile client. The client logic looks at these entity types to check user personas
assignment or assignments and to see if features are enabled. This is used in the mobile client application to
determine which user interface elements should appear on certain screens and sections.
Previously, the application would download all data regardless of enabled or disabled features. This isn’t
optimal and can impact the performance of initial and delta syncs. Now, during the initial sync, the mobile
client makes an online call to fetch the logged on user's persona assignment and entities needed to request in
subsequent calls. The only data downloaded is data needed for the persona:
Use the following topics to configure your personas and features in your mobile application:
SAP Service and Asset Manager for Windows allows a single user to be assigned the Maintenance Technician
Persona role. The table below shows the main functions of the persona.
Note
For more information concerning features supported when using SAP Service and Asset Manager for
Windows, refer to the note [Link] .
CA_AT- Attachment Y
TACH- support for
MENT business ob-
jects (DMS /
BDS / GOS)
CA_BUSI- Business N
NESS_PAR partner
TNER
CA_CLAS- Classifica- Y
SIFICA- tion and
TION characteris-
tics for tech-
nical objects
CA_CRE- Create Y
ATE_TECH equipment
_OBJECT and func-
tional loca-
tion
CA_NO_HI Notification Y
STORY history
CA_TECH_ Equipment Y
OBJECT and func-
tional loca-
tion master
data
PM_CLOC Clock In / N
K_IN_CLO Clock Out
CK_OUT
PM_CON- PM confir- Y
FIRMA- mations for
TION time record-
ing
PM_MEAS Measure- Y
UREMENT ment read-
ings
PM_NOTI- PM notifica- Y
FICATION tions
PM_PRT Production, Y
Resources,
and Tools
(PRT)
PM_SU- Supervisor Y
PERVI- mode
SOR_MOD
E
Professional type of usage is one (1) FUE and Standard is one-half (1/2) FUE. In the base configuration,
Maintenance Technician is defined as a professional user, and Field Service Technician and Inventory Clerk are
Note
The usage type does not necessarily depend on the persona, but rather on the available feature sets. For
example, a single FUE is the maximum value for any individual user that allows access to all available
features, which means that the professional usage type is configured with more feature support than the
standard usage type.
The key difference is when a customer uses a standard Mobile Application Integration Framework (MAIF)
app, such as SAP Service and Asset Manager, and only needs inventory or field service functionality. In this
case, one (1) FUE could cover two users since those personas are standard with only one-half (1/2) FUE
value.
The table below shows what type of usage can be configured for different types of application.
SAP Service and Asset Manager allows a single user to be assigned multiple personas, and she may switch
between them in the Profile Settings screen of the mobile application.
Context
The system determines persona based on the following logic and sequence.
Users may be assigned to one or more personas in the Admin Portal, launched in SAP GUI with
tcode /n/syclo/admin.
This is first considered to determine a user’s persona. If a persona is assigned here, you will not need
to do further checks.
See the following topics and subtopics for detailed information, depending on your back end system:
• Enabling Mobile-Specific Authorization Checks Mobile Add-On for SAP S/4HANA Security Guide
topic and subtopics in the .
• Topic and subtopics in the Enabling Mobile-Specific Authorization Checks topic and subtopics in
the Mobile Add-On for ERP Security Guide.
b. Role-based assignment: Each persona is associated with a pre-defined authorization object in SAP
Service and Asset Manager. Customers may assign the pre-defined authorization objects to users as
needed. The authorization objects are then used to determine the user persona.
These are typically assigned to a role in SAP GUI via t-code PFCG. By default, three standard
authorization objects are delivered:
Customers need to create custom role or roles and assigned authorization objects accordingly based
on own business and security needs.
c. Default persona assignment: If none of the above options are found, the system will use the
preconfigured default persona. The default persona is the Maintenance Technician in the standard
delivery.
Customers can update the default persona based on own business needs by selecting the default
checkbox in the Configuration Panel.
2. Implement your own custom rule, if desired. Select your custom rule in the Auto Determination Rule field.
Context
A new feature created by a customer can only be created in the customer namespace.
Note
As of the SAP Service and Asset Manager 2205 release, enable and disable parameters are no longer
available through the Parameters tab. You enable or disable all features through the Features tab. See the
Configuring Features [page 73] procedure for details.
Procedure
The list of features delivered in SAP Service and Asset Manager is displayed in the Configuration Panel.
You may define new features in a customer namespace only.
Each feature has an Active check mark that you can toggle. This acts as the master switch across the
application.
You can also toggle features related to a persona. Each persona is configured with a list of features
supported in the standard delivery of SAP Service and Asset Manager.
You can view a list of features by persona in the Configuration Panel. Each feature has an In-Scope
checkbox, meaning that the feature is allowed for that persona. In-scope features are not editable in
customer or QA environments. Only In-Scope items can be enabled or disabled using the Active Flag
checkbox.
You can enable a feature for one persona, but disable the same feature for another persona. The list
can be filtered using the User Persona or Application Feature Id drop-down list to find entries directly.
Note that if the feature is disabled at the application-main switch level, the feature is still considered
disabled, regardless of the Active Flag status at the persona level.
2. Click the Change button. Enable or disable desired features.
3. Save your changes.
Results
During mobile client synchronization, all active data objects are sent to the mobile user. For example, if data is
being sent to the mobile user that the client application does not need, this can increase the synchronization
time.
Disable the data objects that are not used in your workflow. Below are several ways to accomplish this.
Like feature assignments, the In-Scope check mark indicates the data objects that are supported for each
feature. Only In-Scope items can be enabled/disabled using the Active Flag check mark, and In-scope
features are not editable in customer or QA systems.
• Exchange Object Assignment: Navigate to Configuration Panel Component Assignments hyperlink
Select Mobile Application (SAP_SERVICE_ASSET_MANAGER_2205) xChange Object Assignment tab .
Features can also be associated with an exchange object that combines technical objects, such as the
exchange class handler, the exchange table and the lock object, with configuration rules.
You can view the list of exchange objects in the Configuration Panel and select the ones you need and
disable the others.
If the exchange object is assigned to a feature, the check mark Activation controlled by Application Feature
will appear next to the Active check mark.
This control is like a master switch; if activation is disabled here, it will be disabled in all places,
regardless of the active flags set in the previously discussed methods. However, it is also important to
note that if an object is active here but disabled by the other methods, the linked exchange will not
be executed when changes are made to the object. This prevents unnecessary exchanges from being
triggered if the feature is not applicable to customers.
There are several entities in the Configuration Panel where it is possible to support activation by feature. This
allows you to go down the hierarchy to manage entities, dependency objects, and more.
• oData Model Entity Type: You can specify a particular entity to be enabled only if the assigned feature
is activated. In the example below, the EAMChecklistLink entity set is applicable to the Enterprise
Asset Management (EAM) checklist functionality. Here only when EAM_CHECKLIST feature is enabled,
EAMChecklistLink is available for the client.
• Association and navigation: Like an entity type, association and navigation can be assigned to a feature.
Only when the assigned feature is enabled does the association become visible to the mobile client.
If the disabled flag is active, the entity will not be visible to the mobile client regardless of whether the
feature is enabled or not.
We only support one feature assignment per object (such as entity type, association, navigation, EFI).
You cannot assign multiple features to an object in the Configuration Panel.
The Component Assignment page allows you to define what features are applicable for each persona.
Context
Using the User Personas tab, you can enable or disable features as desired. For example, PM_CONFIRMATION
is enabled by default, and HR_TIMESHEET is disabled. If your site uses CATS, you can disable
PM_CONFIRMATION and enable HR_TIMESHEET.
The Switchable Features tab allows you to configure OMDOs required for each feature. During initial and delta
syncs, the client only downloads data from the assigned OMDOs. Activating specific OMDOs determines the
entities and data that is downloaded to the mobile device.
Procedure
1. Navigate to Component Assignments from the home page. Select your application in the Mobile Application
Filter dropdown. Click on your application hyperlink in the Search Result table.
2. Click the Change button. Enable or disable desired features using the Active Flag checkbox. Save your
changes.
3. Select the Switchable Features tab.
4. Click the Change button. Enable or disable desired OMDOs using the Active Flag checkbox. Save your
changes.
Note
Don’t select OMDOs that belong to the online service (ex: /MERP/
SAP_ONLINE_LOOKUP_EXT_<version>). These online service entities might not exist in the base
service (/MERP/SAP_ASSET_MANAGER_<version>).
Note
If you don't see an expected feature in the list, ensure it's enabled on the Mobile Application
Configuration Features tab . See the Configuring Features [page 73] procedure for more
information.
After you've enabled or disabled a feature in the Component Assignments page, navigate to Home Mobile
Application Configuration Parameters tab . Find the parameter group and parameter name and maintain the
feature enablement accordingly.
You can search for inventory objects you want to process directly from your mobile device.
Based on the search criteria, the application will search for objects locally or in the backend (if enabled).
Objects matching the oMDO filter values will be returned in the search results.
Note
This filter is cascaded and set to active for all inventory objects oMDO except the physical inventory.
By default, the SAP Service and Asset Manager application maps the STARTED work order status on the client
to the REL status in SAP Mobile Add-On.
In many implementations, a status of MOBI is used in SAP Mobile Add-On to indicate that the work order is
started by a technician. The MOBI status cannot be modified on the back end.
You can map the mobile status to a different status within SAP Mobile Add-On by altering the mobile
application configuration for SAP Service and Asset Manager and changing the system status technical code
for the STARTED mobile status. After you change the system status technical code, updates to SAP Mobile
Add-On made when a user starts a work order set the status in SAP Mobile Add-On to the MoBI status,
matching the entered technical code.
The only modification to make is in the ConfigPanel, in the Mobile Application Configuration page, Mobile Status
Setting tab. Change the mobile status for a started work order in the list of the mobile status options for SAP
Service and Asset Manager, with the system status value of that same record altered to use the technical code
of the desired status.
Prerequisites
• Determine and note the technical code of the work order system status to which the mobile status
STARTED will be mapped, as it is used in the procedure.
• The system status to which you are mapping the mobile status of STARTED in this procedure is configured
as a work order status.
• The person performing this procedure has access to the ConfigPanel and permissions to change
configuration settings of the elements within it.
Context
The following procedure describes the steps required to change a system status when a mobile STARTED
status is mapped to it.
1. Starting from the ConfigPanel home page, click the Mobile Application Configuration link. Then click the
Mobile Status Setting tab.
2. Choose your desired mobile application from the list of Defined Mobile Applications in the left pane.
The application level status settings display in the tab to the right. Information includes the Mobile Status
List.
3. In the Mobile Status List table, find the Object Type of <WORKORDER> with a Mobile Status of <STARTED>
and click the Change button.
4. Change the System Status value to the technical code of the system status to which the STARTED mobile
status should be mapped. When done, click Save.
Results
After completion of the procedure, the STARTED mobile work order status is mapped to a different system
status than the default REL status.
You can enable, disable, and customize parameters related to the auto-syncing of the app in the ConfigPanel.
Context
You can configure the following parameters to customize the auto-syncing of the app in the AUTO_SYNC
parameter group:
1. Ensure the CA_AUTO_SYNC feature is enabled for your personas. See the Configuring Personas and
Features Overview [page 66] topic and subtopics for detailed information.
2. 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. Configure one or more parameters in the AUTO_SYNC group as desired.
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 the value of the parameter isn't
overridden at runtime through synchronization processing.
5. Save your changes.
Prerequisites
Note
As of the SAP Service and Asset Manager 2205 release, enable and disable parameters are no longer
available through the Parameters tab. You enable or disable all features through the Features tab. See the
Configuring Features [page 73] procedure for details.
Use the CatsMinuteInterval parameter when CATS is enabled and the LaborTimeMinutesInterval parameter
when PM confirmations are enabled. The following procedure is the same for either parameter, even though
this guide is using the CATSMinuteInterval parameter as an example.
When a mobile user manually logs their time, or their time is automatically logged for them through the use of
the application, the time logged is rounded to the nearest interval configured. For example, you manually log an
additional 12 minutes of work on a work order on a mobile device. Your CATSMinuteInterval parameter is set to
15. Therefore, your additional time logged is automatically rounded up to 15 minutes. The time entry screens
also have their duration control values limited to minute values matching the configured interval.
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.
2. The CATSMinuteInterval parameter is found in the TIMESHEET group. You can scroll down to find the
parameter, or perform a search using the Search box. Highlight the CATSMinuteInterval parameter and
click the Change button.
Note
If you accidentally set the parameter to an interval value that isn’t an allowed value, the parameter
automatically defaults to a value of 15 on the client device.
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
isn’t overridden at runtime through synchronization processing.
5. Save your changes.
The Clock In Clock Out (CICO) feature decouples time tracking from the mobile status of a work order
or operation, allowing multiple users to start and log time against the same work order or operation
simultaneously.
Overview
Note
As of the SAP Service and Asset Manager 2205 release, enable and disable parameters are no longer
available through the Parameters tab. You enable or disable all features through the Features tab. See the
Configuring Features [page 73] procedure for details.
• Multiple people can work on the same work order or operation even if the work order or operation is
already started by another user
• Users can clock in to any work order or operation on their device
• Users can only clock in to one work order or operation on their device at a time
• Users must clock out of the current work order or operation before clocking in to a different work order or
operation
• All time recording (CATS and Confirmation) uses the clock in clock out period as the default duration in
time entry screens
• When a user clocks in to a work order or operation:
• The timestamp of the work order or operation is saved to a user-specific table that is persisted in the
back end
• The mobile status of the work order or operation is set to Started if it isn’t already in a started state
• When a user clocks out of a work order or operation:
• The work order or operation status is set to either Hold or Complete
• If a work order or operation is set to Complete and Confirmations are used, the user can set it as the
final confirmation
• A user can start any work order or operation that is in a Hold, Received, or Local state
• A user can start only one work order or operation at a time
• The mobile status of a work order or operation is used to track time in either CATS or Confirmations
1. Using the ConfigPanel, navigate to Component Assignments. Select your application in the Mobile
Application Filter. Click the application link in the Search Result table.
The Application Assignment Definitions page displays.
2. Click the Change button. Find the PM_CLOCK_IN_CLOCK_OUT feature ID in the
MAINTENANCE_TECHNICIAN user persona part of the table. Enable or disable the feature using the Active
Flag checkbox.
Context
Use the SIGN_CAPTURE parameter group and the following parameters within the group to configure signature
control for SAP Service and Asset Manager:
Restriction
The digital signature feature is available in SAP S/4HANA 2020 and above releases. The digital signature
feature is not available for SAP ERP systems or SAP S/4HANA systems lower than 2020.
By default, the signature control feature is not enabled. To enable signature control:
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. Enable the parameter as follows:
• Y: Control is displayed on the client and is required before completing the object
• N: Control is not displayed on the client (enabled by default)
• O: Control is displayed on the client and is an optional step to complete the object
Note
If the parameters have no Parameter Value assigned, signature control does not display on the client.
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.
• oMDO class
• oData Model Entity Type Name
This works so that only Y or Z namespace can be used in the user SAP system while only the partner
namespace is allowed in the partner system.
With SAP Service and Asset Manager 2210 or earlier versions, you can bypass namespace checks by setting
the NO_NAMESPACE_CHECK runtime parameter to X. Namespace bypass is not applicable to the Persona and
Feature configuration, whereby a custom or partner namespace remains applicable in those areas and cannot
be bypassed.
Note
As of SAP Service and Asset Manager 2305, you can no longer use the runtime parameter to
bypass namespace check. A custom or partner namespace is enforced in the above mentioned
configuration areas. For more information on how to set the runtime parameter, see the https://
[Link]/#/notes/2713969 SAP note.
The digital signature feature performs a verification of work by digitally signing for the work using a user
name and password. The digital signature framework is able to create digital signature verification by using
a back-end user name and registered time-based one-time password, or TOTP. The TOTP is brought by the
CL_TOTP object.
The digital signature UI5 reuse component provides an OData service that allows for direct online interaction
by the client to register a digital signature completed work.
The Digital Signature feature is called CA_DIGITAL_SIGNATURE. By default, the feature is not enabled.
Note
As of the SAP Service and Asset Manager 2205 release, enable and disable parameters are no longer
available through the Parameters tab. You enable or disable all features through the Features tab. See the
Configuring Features [page 73] procedure for details.
For complete information on digital signature, see the Digital Signature guide, specifically the Implementation
Guide for UI5 Reuse Component topic and subtopics.
• SAP Service and Asset Manager digital signature relies on the CL_TOTP object interface.
• SAP Service and Asset Manager digital signature uses a connection to the UI5 Reuse component in digital
signature. The UI5 Reuse component provides the ability to digitally sign different objects.
• Digital signature support from SAP Service and Asset Manager is only available on an SAP S/4HANA 2020
or later back end system. Digital signature is therefore available for SAP Service and Asset Manager 2105
or later releases installed on a SAP S/4HANA 2020 or later back end system.
• Digital signature is supported with any two-eyed (2E) strategy. Out of the box, the TOTP_2E strategy is
used. TOTP_2E is the two-eyed principle of a technician signing the operation for their work. You can
configure the 2E strategy by navigating to OData Mobile Data Object Configuration Data Filter . Select
the SAM2305_DSIG_CONFIGURATION OMDO with the filter SIGNATURE_STRATEGY.
Prerequisites
Ensure you're following all points discussed in the Limitations section of the Digital Signature Overview [page
90] topic.
An authenticator application, such as Microsoft Authenticator, must be installed on the mobile device, in order
to use the TOTP process.
1. Create a destination in SAP Business Technology Platform Mobile Services (SAP BTP services): Create
a specific destination in SAP BTP services that points to the digital signature service.
The digital signature service must be exposed to the back-end gateway in transaction /n/IWFND/
MAINT_SERVIVCE. The external service name that must be exposed is ODATA_DIGITAL_SIGNATURE_SRV.
If a front-end service exists, expose the digital signature service in the same way you expose other services.
2. Expose the service on SAP BTP services: Create a mobile destination and attach it to the SAP Service
and Asset Manager 2305 application. The destination name is DEST_DIGITAL_SIGNATURE_PPROP with
the URL pointing to the back-end service for digital signature.
Procedure
1. Use transaction code SU3 on the SAP GUI. Choose TOTP Registration from the menu options.
The Administration of TOTP Devices window appears. The TOTP Devices table should contain a default
entry. If the entry is missing, continue this procedure.
2. Open the Administration & Monitoring Portal through the transaction code /n/SYCLO/ADMIN. Select the
Administration tab.
4. Select the appropriate entry from the Search Result section. Click the Preference Info tab.
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 Service and Asset Manager:
• CatTypeActivities: Default is A
• CatTypeCauses: Default is 5
• CatTypeDefects: Default is C
• CatTypeObjectParts: Default is B
• CatTypeTasks: Default is 2
• CatalogProfileOrder: Default is Equipment, Functional Location, Notification Type
The CATALOGTYPE parameters correspond to the rules found in the OData mobile data object
SAM2305_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.
2. The CatType[xxx] parameters are found in the CATALOGTYPE group. You can scroll down to find the
parameter, or perform a search using the Search box. Highlight the parameter you want to configure and
click the Change button.
6. If you are creating a custom activity value type, navigate to OData Mobile Data Object Configuration
Data Filter Tab SAM2305_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 131].
8. Save your changes.
Using parameter framework configuration, configure parameters to enable or disable various features per the
authorization of the user in the back end.
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.
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
SAP ASSET MAN- Create work order Work Orders IW31 [Link] Includes opera-
tions and suboper-
AGER
ations
SAP ASSET MAN- Edit work order Work Orders IW32 [Link] Includes opera-
tions and suboper-
AGER
ations (except lo-
cal)
SAP ASSET MAN- Create Notification Notifications IW26 [Link] Includes items,
tasks, and activi-
AGER
ties
SAP ASSET MAN- Edit Notification Notifications IW22 [Link] Includes items,
tasks, and activi-
AGER
ties (except local)
SAP ASSET MAN- Edit FLOC Functional Loca- IL02 [Link] Includes adding
tion characteristics
AGER
(except local)
SAP ASSET MAN- Edit equip Equipment IE02 [Link] Includes adding
AGER characteristics, in-
stall, and disman-
tle (except local)
SAP ASSET MAN- Equip attachment Attachments N/A [Link] See the Ge-
upload neric Authorization
AGER
Check section in
this topic
SAP ASSET MAN- FLOC attachment Attachments N/A [Link] See the Ge-
upload neric Authorization
AGER
Check section in
this topic
SAP ASSET MAN- Allow final confir- Confirmation N/A [Link]- See the Ge-
mation [Link] neric Authorization
AGER
Check section in
this topic
SAP ASSET MAN- Issue and return MIGO N/A [Link] See the Ge-
parts neric Authorization
AGER
Check section in
this topic
ASSET CENTRAL Add checklist Checklist N/A [Link] See the Ge-
neric Authorization
Check section in
this topic
ASSET CENTRAL Fill checklist Checklist N/A [Link] See the Ge-
neric Authorization
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.
See the following screenshot for an example of a configured user role parameter:
Use the rule /SMFND/CL_CORE_AUTH_CHECK_RU - TCode Authorization Check to enable a more generic
authorization check. This rule is used for the following parameters:
• [Link]
• [Link]
• [Link]
• [Link]
• [Link]
• [Link]
• [Link]
Context
There are three core configuration steps to implement mobile user attributes:
Procedure
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.
Context
If you enable the EnableOnLocalBusinessObjects parameter, SAP Service and Asset Manager allows mobile
status update changes for the following:
1. Navigate to Mobile Application Configuration Parameters tab using the ConfigPanel. Select your
application in the left column, Defined Mobile Applications.
The Parameter List populates with a list of all parameters available for the application.
2. Find the EnableOnLocalBusinessObjects parameter in the MOBILESTATUS group. Scroll down to find the
parameter, or perform a search using the Search box. Highlight the parameter you want to configure and
click the Change button.
3. Enable or disable the parameter using the following strings: Y, Yes, T, or True are used to enable the
parameter. N, No, F, or False are used to disable the parameter.
4. Check the <Active> flag to ensure that the parameter is used by the mobile application. Check the <No
Runtime Change> box to ensure that the value of the parameter isn’t overridden at runtime through
synchronization processing if desired and if not already checked.
5. Save your changes.
Abstract document management provides the option to create and read DMS, GOS, or BDS documents
without configuration at the client application level.
Hover over the different types of abstract document in the flow chart to view the specific flow chart for the
document type.
Abstract document management provides the option to create and read DMS, GOS, or BDS documents
without configuration at the client application level.
Prerequisites
Address the following items before performing the procedure:
• Know the status or statuses that you’re filtering on for equipment synchronization, as they’re used in the
procedure
• Ability to access to the ConfigPanel and permissions to change configuration settings
With a standard activation of a DMS or GOS document management solution, each document type has its
own default content repository. Any application consuming document solutions like DMS or GOS follow the
back-end configuration settings.
Select SAM2305_DOCUMENT from the oData Mobile Data Object List and navigate to the following locations:
When you require SAP Service and Asset Manager to create content in a custom repository that
is different than your back-end configuration, use the OTHER option. Implement the BADI /MERP/
IF_CORE_OMDO_ABSDOC_BADI CREATE_OTHER_DOCUMENT . Your implementation must match with the
ABS data model to work with standard SAP Service and Asset Manager metadata. See the Other Method [page
112] flow chart for more information.
Beginning with the SAP Service and Asset Manager 2010 release, SAP Service and Asset Manager supports
working with third-party repositories like Open Text or HTTP. Using third-party repositories leverages the back-
end configuration for GOS, BDS, or DMS for work orders, notifications, equipment, and functional locations.
See 2945017 to configure older application releases to work with third part repositories.
When using DMS, create custom storage category ZEXT to link to a third-party repository, such as an Open
Text content server. See 2945017 for more information. Through this additional configuration, attachments
uploaded from the application are stored in the third-party content server rather than the default content
server.
See the following release notes for addition information on configuring abstract documents:
Note
It isn't possible to integrate ABS documents with third-party repositories. Use this SAP note to deliver
additional parameters such as storage category at an object level.
See the following examples of back-end configuration with a third-party content server:
Example 1
Configure third-party repositories like Open Text to work with one of the available document solutions like BDS,
DMS, or GOS using the ConfigPanel. Then apply SAP Note 2945017 and configure the desired document
solution for work orders, equipment, and functional location objects.
Example 2
Integrate a third-party repository in more than one way with your back-end SAP system. If your implementation
doesn’t fit with DMS, BDS, or GOS, use the OTHER option in the ConfigPanel. Implement BADI /MERP/
CORE_OMDO_ABSDOC_BADI to align with the implementation.
When taking readings in the SAP Service and Asset Manager mobile app, you can attach documents
related to S4 service orders, requests, confirmations, contracts, and related items. Activate S4 on the
SAM2305_DOCUMENT data filter to attach documents to S4 objects.
1. Select SAM2305_DOCUMENT in the oData Mobile Data Object List and navigate to the following:
• Operation CREATE_MEDIA Data Segment DOCUMENT_SWITCH
• Operation READ Data Segment DOCUMENT_SWITCH
2. In the Rule List, activate the following objects:
• BUS2000116: Service Order
• BUS2000117: Service Confirmation
• BUS2000223: Service Request
Note
Context
Procedure
1. Select SAM2305_S4_SERVICE_ORDER in the oData Mobile Data Object list and navigate to the Data Filter
tab.
4. Enable dependency between the S4 service order and the related document on the mobile device.
5. Navigate to the Dependent Object tab. Find the S4SERVDOCUMENT object in the <Source Tech. Entity
Type> column. Scroll the page to find the SAM2305_DOCUMENT object. Ensure it is marked as Active.
6. Insert the two lines in the Dependent Object Keys tab:
1. Source oMDO Field Name: OBJECT_KEY
Dependent Object Key Fieldname: OBJECT_KEY
2. Source oMDO Field Name: OBJTYPE_H
Dependent Object Key Fieldname: OBJECTLINK
7. Insert the two lines in the Origin Object Keys tab:
1. Field name: OBJECT_KEY
2. Field name: DOC_OBJ_ID
8. Enable dependency between the S4 service order item and the related document on the mobile device.
9. Navigate to the Dependent Object tab. Find S4SERVITEM object in the <Source Tech. Entity Type> column.
Scroll the page to find the SAM2305_DOCUMENT object. Ensure it is marked as Active.
10. Insert the two lines in the Dependent Object Keys tab:
1. Source oMDO Field Name: ITEM_GUID_CHAR
Dependent Object Key Fieldname: OBJECT_KEY
2. Source oMDO Field Name: OBJTYPE_I
Dependent Object Key Fieldname: OBJECTLINK
11. Insert the three lines in the Origin Object Keys tab:
1. Field name: OBJTYPE_H
2. Field name: OBJECT_ID
3. Field name: NUMBER_INT
Context
Procedure
1. Select SAM2305_S4_SERVICE_REQUEST in the oData Mobile Data Object list and navigate to the Data
Filter tab.
2. In the Defined Filters list, navigate to Operation READ Standard Filter ABS_DOC_TYPE.
3. Set the filter handler
OMDO_ID=SAM2305_DOCUMENT&OPERATION=READ&DOF_NAME=DOCUMENT_SWITCH&OBJECTLINK
S=BUS2000223&OBJECT_TYPES=BUS2000223 to Active.
4. Enable dependency between the S4 service request and the related document on the mobile device.
5. Navigate to the Dependent Object tab. Find the S4SERVDOCUMENT object in the <Source Tech. Entity
Type> column. Scroll the page to find the SAM2305_DOCUMENT object. Ensure it is marked as Active.
6. Insert the two lines in the Dependent Object Keys tab:
1. Source oMDO Field Name: OBJECT_KEY
Dependent Object Key Fieldname: OBJECT_KEY
2. Source oMDO Field Name: OBJTYPE_H
Dependent Object Key Fieldname: OBJECTLINK
7. Insert the two lines in the Origin Object Keys tab:
1. Field name: OBJECT_KEY
2. Field name: DOC_OBJ_ID
Context
Procedure
1. Select SAM2305_S4_SERVICE_CONFIRMATION in the oData Mobile Data Object list and navigate to the
Data Filter tab.
2. In the Defined Filters list, navigate to Operation READ Standard Filter ABS_DOC_TYPE.
3. Set the filter handler
OMDO_ID=SAM2305_DOCUMENT&OPERATION=READ&DOF_NAME=DOCUMENT_SWITCH&OBJECTLINK
S=BUS2000117&OBJECT_TYPES=BUS2000117 to Active.
4. Enable dependency between the S4 service confirmation and the related document on the mobile device.
5. Navigate to the Dependent Object tab. Find the S4SERVDOCUMENT object in the <Source Tech. Entity
Type> column. Scroll the page to find the SAM2305_DOCUMENT object. Ensure it is marked as Active.
6. Insert the two lines in the Dependent Object Keys tab:
1. Source oMDO Field Name: OBJECT_KEY
Dependent Object Key Fieldname: OBJECT_KEY
2. Source oMDO Field Name: OBJTYPE_H
Dependent Object Key Fieldname: OBJECTLINK
7. Insert the two lines in the Origin Object Keys tab:
1. Field name: OBJECT_KEY
2. Field name: DOC_OBJ_ID
8. Enable dependency between the S4 service confirmation item and the related document on the mobile
device.
9. Navigate to the Dependent Object tab. Find S4SERVITEM object in the <Source Tech. Entity Type> column.
Scroll the page to find the SAM2305_DOCUMENT object. Ensure it is marked as Active.
Context
Procedure
1. Select SAM2305_S4_SERVICE_CONTRACT in the oData Mobile Data Object list and navigate to the Data
Filter tab.
2. In the Defined Filters list, navigate to Operation READ Standard Filter ABS_DOC_TYPE.
3. Set the filter handler
OMDO_ID=SAM2305_DOCUMENT&OPERATION=READ&DOF_NAME=DOCUMENT_SWITCH&OBJECTLINK
S=BUS2000112&OBJECT_TYPES=BUS2000112 to Active.
4. Enable dependency between the S4 service contract and the related document on the mobile device.
5. Navigate to the Dependent Object tab. Find the S4SERVDOCUMENT object in the <Source Tech. Entity
Type> column. Scroll the page to find the SAM2305_DOCUMENT object. Ensure it is marked as Active.
EAM processes need checklists for actions such as inspections and maintenance. SAP Service and Asset
Manager uses EAM checklists with work orders and operations.
Note
This core feature is only available on an SAP S/4HANA 2021 or later back end system. This feature is
therefore available for SAP Service and Asset Manager 2110 or later releases installed on an SAP S/4HANA
or later back end system.
Find the EAM checklist feature in the OMDO handler /MERP/CL_PM_INSPECTION_LOT_OD, as an existing
entity. Features of inspection lot are reused to implement the EAM checklist functionality, along with a new
entity, EAMChecklistLink. Access the OMDO handler through transaction SE24 on your back end system.
You can view the new entity in the ConfigPanel by navigating to oData Model Configuration Mobile App
SAP_ASSET_MANAGER_<version> /MERP/SAP_ASSET_MANAGER_<version> EAMChecklistLink .
Context
The EAM Checklist feature is called EAM_CHECKLIST. By default, the feature is not enabled.
Note
As of the SAP Service and Asset Manager 2205 release, enable and disable parameters are no longer
available through the Parameters tab. You enable or disable all features through the Features tab. See the
Configuring Features [page 73] procedure for details.
1. Navigate to Component Assignments. Select your application in the Mobile Application Filter. Click the
application link in the Search Result table.
If you've enabled the checklist feature, the inspection results display on a mobile device on the Checklists
detail screen. Validation of all inspections results is done per limits set during configuration of inspection
characteristics in the inspection plan. Once results on the mobile device are synced to the back end, the
results and usage decision are updated. The EAM checklist is marked as complete on the mobile device.
4. Enable the dependency between a work order and a related inspection lot on the mobile device. Navigate
to SAM2205_WORK_ORDER_GENERIC oMDO.
5. Select the Dependent Object tab. Find the WOHEADER objects in the <Source Tech. Entity Type> column.
6. Find the SAM<version>_INSPECTION_LOT object. Enable the feature using the Active checkbox.
Context
The functionality for creating defects manually for a rejected inspection task result from the mobile device is
enabled through the Parameters tab. The EAM checklist feature is enabled by default.
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.
The parameters found in the EAM_CHECKLIST group work alongside the order type configuration to
automatically create the defects upon results recording. When the parameter is enabled, the Record Defct
button on a rejected inspection characteristic is availabe on the app. A technician can add defect details.
The app creates a notification on the back end when the mobile device is synced for the default EAM defect
notification type assigned to that order type.
3. Make your desired parameter association changes. Enable the parameter as follows:
• Y: Select if work order types are not set up with automatic defect recording
• N: Select if you've configured work order types set up with automatic defect recording
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.
When enabling EAM on the SAM2305_DOCUMENT data filter, you can attach documents to inspection lots.
And when taking readings in the SAP Service and Asset Manager mobile app, you can attach documents
related to the inspection lots.
1. Select SAM2305_DOCUMENT in the oData Mobile Data Object List and navigate to the following:
• Operation CREATE_MEDIA Data Segment DOCUMENT_SWITCH
• Operation READ Data Segment DOCUMENT_SWITCH
2. Add new lines to the Rule List for BDS and GOS:
• OBJECT_TYPE: BUS2045
• OBJECTLINK: BUS2045
Note
Note
Context
Procedure
1. Select SAM2305_INSPECTION_LOT in the oData Mobile Data Object List and navigate to the Data Filter tab.
2. In the Defined Filters list, navigate to Operation READ Standard Filter ABS_DOC_TYPE
3. Set filter handler
OMDO_ID=SAM2305_DOCUMENT&OPERATION=READ&DOF_NAME=DOCUMENT_SWITCH&OBJECTLINK
S=BUS2045,QALS&OBJECT_TYPES=BUS2045 to Active.
Note
As of 2305 version, the SAP Service and Asset Manager introduces an additional feature
concerning long texts for master inspection characteristics: a new MasterInspectionCharLongText
entity is created as an InspectionLot sub-entity. Set the flag to Insp_Lot_On_Demand to enable
reading the long text of the main inspection characteristic. By default, it is active.
You can create Equipment and Functional Locations from the SAP Service and Asset Manager application in a
similar way to executing transactions IE01 and IL01 from the SAP Service and Asset Manager GUI.
Context
A template is required when you create equipment, but it's optional when you create a functional location. Any
existing equipment or functional location can be used as a template. It's possible to copy the classifications,
measuring points, business partners, documents, install location (equipment only), and notes from the
template. The description, maintenance plant, start date, manufacturer, date of manufacturer, model number,
serial number, and room are populated from the template object and you can overwrite them. It's possible to
update equipment and functional location before syncing.
Procedure
1. To access the ConfigPanel using a direct transaction code shortcut, enter /n/syclo/configpanel.
2. Activate CA_CREATE_TECH_OBJECT for MAINTENANCE_TECHNICIAN Persona in the Component
Assignments.
The PROPERTY_FLAG filter in the technical objects, either Equipment or Functional Location oMDO contains
the list of properties available to edit during the creation of a technical object. The properties, which are active
by default correspond to the default fields in the applications technical object create page, see the example.
EQUIPDESC corresponds to the Description field in the Equipment create page of the app.
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 Service and
Asset Manager, you may need to adjust the rules for one or more of the oMDO filters.
Many of the filters in SAP Service and Asset 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 Service and Asset 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
1. Access the ConfigPanel. See Accessing the SAP Mobile Add-On for SAP Configuration Panel [page 13] for
information.
2. From the ConfigPanel Home page, click the oData Mobile Data Object Configuration link.
3. At the top of the oData Mobile Data Object Configuration page display, in the Mobile Application Filter
field, choose your mobile application from the dropdown menu. Choosing your mobile application is not a
necessary step, but it eliminates objects that are not part of your mobile application from the object list.
4. Click the Data Filter tab.
5. Expand the oData Mobile Data Object List tree so you can see all of the oData mobile objects.
6. Select the oData mobile data object that requires filter modification from the list.
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. For a detailed
description of all oData mobile data object fields, see the OData Channel Integration Settings topic and and
the related subtopics in the Configuration Panel Overview [page 14] section.
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.
In the default configuration of SAP Service and Asset Manager, work orders are distributed to technicians
based on basic parameters. Your site may wish to distribute work orders to users based on the order type.
By default, all Plant Maintenance specific order types are included in the synchronization logic for the SAP
Service and Asset Manager application.
In many environments, one or more order types are added to SAP Mobile Add-On specifically for work orders
that are distributed to technicians. The added order types indicate that SAP Service and Asset Manager will
only download certain specified work orders. To support this distribution method, change the data filter rules of
the OMDOs involved in work order synchronization. The OMDOs include:
• SAM2305_ORDER_TYPE
• SAM2305_WORK_ORDER_GENERIC
Creating rules based on work order types affects synchronization processing and work order downloads to the
mobile devices of your users.
Prerequisites
• The order types for work orders that are downloaded to technicians using the SAP Service and Asset
Manager application are already determined.
• The person performing the procedure has access to the Config Panel and permissions to change settings.
The following procedure modifies the synchronizing behavior of the SAP Service and Asset Manager
application so only work orders with a given order type or types are downloaded to the client. In the procedure,
you’ll change the ORDER_TYPE filter in the OMDOs involved in work order synchronization. Specifically, you
add rules to the filter in each OMDO to include only the desired work order types. You add a rule for each order
type to include.
If you don’t create a rule for a work order type, then those work order types are excluded from the work order
download synchronization processing. If the work orders are excluded from the synchronization processing,
then the work orders aren’t present on the mobile clients of your users.
Procedure
1. From the Config Panel home page, click the OData Mobile Data Object Configuration link, then click the
Data Filter tab. Be sure to have your desired mobile application chosen in the Mobile Application Filter field
at the top of the page.
2. Expand the OData Mobile Data Object by Mobile App list on the left and click SAM2305_ORDER_TYPE.
3. Expand the Standard Filter in the Defined Filters pane, and click the ORDER_TYPE filter.
4. View the rule list for the filter, which is empty in the default configuration of SAP Service and Asset
Manager. Click the Change button.
5. Create a rule for each order type included in the work order distribution to the SAP Service and Asset
Manager technicians. The settings for the rule are as follows:
• DOF Rule Type: Static Value in Range Format
• Sign: Inclusive
• Option: =
• Low Value: The desired order type
For more details on adding or editing filter rules, see Changing oData MDO Filter Rules [page 131].
6. Save your changes once you’re finished.
7. Find and click the SAM2305_WORK_ORDER_GENERIC OData mobile data object on the list on the left.
8. Expand the Operation - READ Data Distribution in the Defined Filters pane, and click the
ORDER_TYPE filter.
9. View the rule list for the filter, which is empty in the default configuration of SAP Service and Asset
Manager. Click the Change button.
10. Create a rule for each order type included in the work order distribution to the SAP Service and Asset
Manager technicians, as you did with the previous OMDO filter. The settings for the rule are as follows:
• DOF Rule Type: Static Value in Range Format
• Sign: Inclusive
• Option: =
• Low Value: The desired order type
11. Save the changes.
After you finish the procedure, work orders are downloaded by the SAP Service and Asset Manager application
only if their work order type is set to a type for which a filter rule was created. Other work order types aren’t
retrieved by the application.
Business object distribution defines the data that needs to be downloaded to the mobile device based on the
resource planning of technicians for different business objects, such as work order and notification. You can
use this configuration to define which technicians has to complete which activities on the mobile device.
Implementation environments in different business industries or business types may use a different business
object model from the default to determine the proper technician assignment for a business object such work
order and notification.
By default, the SAP Service and Asset Manager application determines the assignment of a work order using
the personnel number of the work order header. However, you can make minor configuration changes to
support several work assignment models.
For some customers using Assignment Type 3 for work orders,viewing a list of suboperations is more important
than viewing a list of operations. Work order headers are still visible. You can configure your preference using
the ConfigPanel for SAP Service and Asset Manager.
For assignment types 2 and 6, some customers prefer the ability to view all operations rather than all work
orders. Work order headers are still visible. You can configure your preference using the ConfigPanel for SAP
Service and Asset Manager.
Implementation environments in different business industries or business types may use a different business
model from the default to determine the proper technician assignment for a work order.
The following assignment types are supported with minor configuration changes:
Note
• Assignment Type 1: Header-level person responsible for the work order (default, no change required)
• Assignment Type 2: Operation-level personnel number of the work order
• Assignment Type 3: Sub-operation-level personnel number of the work order
• Assignment Type 4: Capacity requirement personnel assignment
• Assignment Type 5: Header-level planner group*
Prerequisite: Mobile user has to have the user parameter IHG set up in the user profile parameter.
• Assignment Type 6: Operation- or task-level work center*
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 SAM2305_WORK_ORDER_GENERIC, and then the Data Filter
tab.
3. Expand the Defined Filters list as follows; Operation - READ Data Distribution and click
WO_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.
Note
If you’re configuring an operation level assignment type, you must update the OPER_EXCL_SYST_STAT
filter with the I0009 - CNF:Confirmed value. However, remove the value if you’re configuring a header
level assignment type.
By default, the SAP Service and Asset 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:
Note
The SAP HR module is required for Assignment Type 1 and Assignment Type 2.
• Assignment Type 1: Header-level person responsible for the notification assignment (default, no change
required)
• Assignment Type 2: Task-level personnel number of the notification assignment
• Assignment Type 3: Header-level planner group*
Prerequisite: Mobile user has to have the user parameter IHG set up in the user profile parameter.
• Assignment Type 4: Header-level business partner*
• Assignment Type 5: Header-level of the work center*
Prerequisite: Mobile user has to have the user parameter AGR set up in the user profile parameter.
• Assignment Type D: Dependent Queue
By default, this assignment is based on the technician’s notification assignment dependent collection*.
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 SAM2305_NOTIFICATION_GENERIC, 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 Asset Manager client. Therefore, you can employ
more filtering based on the status of equipment.
By default, SAP Asset 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 Asset Manager client,
modify the SAM2305_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 Asset 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 SAM2305_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
Use the following procedure to create a filter rule for the OMDO, SAM2305_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 Asset 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 Asset Manager application are
filtered to only include records with the status or statuses configured in the filter rules.
Next Steps
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.
• 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 SAP Mobile Add-On
• 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
SAM2305_CATS_TIMESHEET. 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
CatsTimesheet. See Setting up an OData Mobile Data Object [page 219] for more information.
By default, follow-on work orders are enabled in a new installation. You can configure if a follow-on link exists or
doesn’t exist at the time of a new work order creation.
Note
Ensure that business function Enterprise Asset Management Part 7 (LOG_EAM_CI_7) is activated in the
back end. See Creating Follow-On Orders for more details.
Context
Procedure
Prerequisites
Be sure that you have installed the Customer Service component. See the instructions in the Asset Manager
Component Installation Guide for IOS for more information.
Note
Configuring Customer Service order types is optional and is required only if the Customer Service
component is enabled.
Procedure
6. Select SAM2305_WORK_ORDER_GENERIC from the list. Then select Data Filter tab Operation - READ
Data Distribution ORDER_TYPE
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.
7. To activate the Customer Service order type, click Change.
Results
Prerequisites
Be sure that you have installed the Customer Service component. See the instructions in the Asset Manager
Component Installation Guide for IOS for more information.
Note
Configuring Customer Service notification types is optional and is required only if the Customer Service
component is enabled.
Procedure
6. Select SAM2305_NOTIFICATION_GENERIC from the list. Then select Data Filter tab Operation - READ
Data Distribution NOTIF_TYPE
Results
You can use either the USE_USER_TIME_ZONE or the POSTING_DATE filter, found in the
SAM2305_PM_CONFIRMATION OMDO, to configure confirmation posting dates. Note that you can enable
only one filter at a time. If both filters are enabled, you'll get an error.
USE_USER_TIME_ZONE Filter
See the Configuring Confirmation Posting Date Using the USE_USER_TIME_ZONE Filter [page 143] procedure
for detailed instructions.
When the SAP system and mobile users are in different time zones, use the USE_USER_TIME_ZONE filter to
perform the time zone conversion. When the filter is active, the application uses the time zone of the mobile
user in the back end system to convert the actual start date / time. It also converts the finish date / time
received from the mobile client. The system time zone is the default setting. The User Time Zone filter is a back
end only configuration.
Note
To use the time zone handling functionality in confirmation, SAP system must be customised with time
zone. If SAP system time zone isn't maintained and the USE_USER_TIME_ZONE filter is active in the
SAM2305_PM_CONFIRMATION OMDO, posting of confirmation from SAP Service and Asset Manager
raises an error.
POSTING_DATE Filter
See the Configuring Confirmation Posting Date Using the POSTING_DATE Filter [page 144] procedure for
detailed instructions.
Context
Use the following procedure if you're configuring the confirmation posting date using the
USE_USER_TIME_ZONE filter.
Procedure
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. Click on oData Channel Integration Settings oData Mobile Data Object Configuration .
3. In the OData Mobile Data Object List select SAM2305_PM_CONFIRMATION, and then the Data Filter tab.
4. Expand the Defined Filters list as follows: Operation - CREATE Standard Filter
USE_USER_TIME_ZONE . Click the Change button.
5. Select the existing rule. Ensure the <Low Value> field is set to X - True and is enabled:
Context
Use the following procedure if you're configuring the confirmation posting date using the POSTING_DATE filter.
Procedure
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. Click on oData Channel Integration Settings oData Mobile Data Object Configuration .
3. In the OData Mobile Data Object List select SAM2305_PM_CONFIRMATION, and then the Data Filter tab.
4. Expand the Defined Filters list as follows: Operation - CREATE Standard Filter POSTING_DATE .
Click the Change button.
5. Select the existing rule. Ensure the <Low Value> field is set to 1 and is enabled:
• Default: 1 - Date from Mobile Device without conversion
• 2 - User Time Zone Date (at the time of BAPI execution)
• 3 - System Time Zone Date (at the time of BAPI execution)
The Parameter List populates with a list of all parameters available for the application.
8. Click the Change button.
9. Find and highlight the PostingDateFromUserOverride parameter, located in the PMCONFIRMATION
parameter group. Set the parameter to one of the following:
• N: (Default). If set to N, the confirmation posting date is automatically taken from the time zone set on
the mobile client.
• Y: If set to Y, the mobile client user can manually enter a date on the Confirmation screen in the app.
10. 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
isn't overridden at runtime through synchronization processing.
11. Save your changes.
Technician Role:
Note
Allowed status transitions are shown by red lines. Status transitions marked by red are only available when
the PM_SUPERVISOR_MODE feature is active. All other transitions are available by default. The supervisor
approves or disapproves the operation after it enters the Review mode by a technician.
Supervisor Role:
Here the user is a supervisor and is logged in as a supervisor. These state transitions are available even if
the PM_SUPERVISOR_MODE feature is inactive. However, a scenario in which the supervisor configuration
and authorization in the backend exists without the PM_SUPERVISOR_MODE feature active is unlikely.
Note
Feature PM_SUPERVISOR_MODE is active. Allowed status transitions are shown by red lines.
Working as a Technician:
Note
Working as a Supervisor:
Here is the action matrix for the maintenance technician persona when the phase model feature is in the active
state.
Note
SAP Service and Asset Manager 2305 allows you to handle both phase and non-phase model work orders
simultaneously by adding the PhaseModelActive flag to the OrderTypes entity.
Approve No Yes No No
Disapprove No Yes No No
Context
The following assignment types are supported when using the Supervisor module:
Configure the assignment types for the work order OData MDO as follows:
Note
One of the assignment types must be configured for the technician, while the other assignment type must
be configured for the supervisor based on the supported work assignment types. Only the same level of
assignment types is supported. In this, you can configure either header level assignments or operation level
assignments, and not both.
Procedure
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 SAM2305_WORK_ORDER_GENERIC, and then the Data Filter
tab.
3. Expand the Defined Filters list as follows; Operation - READ Data Distribution and click
WO_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.
Note
If you’re configuring an operation level assignment type, you must update the OPER_EXCL_SYST_STAT
filter with the I0009 - CNF: Confirmed value. However, remove the value if you’re configuring a header
level assignment type.
Configure the data filters to define the Supervisor role and Team Assignment types for the OMDO. Your specific
configuration is based on how the supervisor team is maintained in the back end.
For detailed instructions on how to work with data filters, see the Working with oData MDO Filter Rules [page
131] and Changing oData MDO Filter Rules [page 131] topics.
In addition to configuring the data filters found in the SAM2305_USER_ROLE OMDO, you must manually
maintain the team assignments for each user in the Mobile Administration and Monitoring Portal. Information
on configuring user parameters is found at the following locations:
The following team assignment types are supported for downloading the supervisor team:
• 1 - Work Center Assignment: Use when the team (technicians and supervisors) is maintained in the back
end through the Work Center Maintenance transaction (CR02/CR03)
• 2 - Organizational Structure Assignment: Use when the team is maintained in the back end through the
Org. Structure Assignment (PPOMA transaction).
• 3 - User Attribute Assignment: Use when the team isn't maintained in the back end through either the
Work Center Maintenance or the Org. Structure Assignment transactions. Additional configuration and
manual team assignments are needed.
• 4 - Custom Assignment: Use by the customer to define custom logic for downloading the
teams. Customer logic is implemented in the BADI method /MERP/CA_OMDO_USER_ROLE_BADI -
GET_ASSIGNMENT_OTHERS.
The position role type filter defines the Position Org ID for the supervisor, and is maintained as part of the team
configuration in the back end. The definition is needed to identify the mobile user with the Supervisor role. It's
also needed for Team Assignment types 1 and 2.
The work center role type filter is used for Team Assignment type 3. When using Team Assignment type 3,
create a new filter rule with the following properties:
Configure the data filters to define the Supervisor role and Team Assignment types for the OMDO. Your specific
configuration is based on how the supervisor team is maintained in the back end.
For detailed instructions on how to work with data filters, see the Working with oData MDO Filter Rules [page
131] and Changing oData MDO Filter Rules [page 131] topics.
You're configuring the ORDER_ACTIVITY_TYPE data filter found in the SAM2305_ORDACTTYPE OMDO.
If <Order Type> and <MaintActiv Type> fields are specified, the supervisor approval functionality is
enabled for the combination:
Context
Note
As of the SAP Service and Asset Manager 2205 release, enable and disable parameters are no longer
available through the Parameters tab. You enable or disable all features through the Features tab. See the
Configuring Features [page 73] procedure for details.
Note
As of the SAP Service and Asset Manager 2305 release, SAP introduces a new parameter for the supervisor
that allows you to enable auto completion on approval. See the configuration procedure below.
The Supervisor feature is called PM_SUPERVISOR_MODE. By default, the feature is not enabled.
To configure the supervisor options for SAP Service and Asset Manager, use the SUPERVISOR parameter
group and the following parameters within the group:
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 for the application.
2. The supervisor parameters are found in the SUPERVISOR group. You can scroll down to find the parameter,
or perform a search using the Search box. Highlight the parameter you want to configure and click the
Change button.
Note
If the Parameter Value field and the Rule ID fields are blank, and if no data filter rule is created, the
authorization model is not used. The UserRoles entity set is then used to determine the authorization
role.
Note
By default status settings for the supervisor mode aren't mapped to any back-end user or system status.
For an example of how to configure a mapping status, see the Changing the Mapping of a Mobile Status to
STARTED [page 82] procedure.
The following statuses to support the supervisor functionality are available at the work order and operation
levels, depending on your configuration of the work order assignment type:
• REVIEW: Set by the technician after they've completed their work. The supervisor is then required to
review the work.
• APPROVE and DISAPPROVE
Note
ACCEPTED and REJECTED: Set by the field service technician if he is rejecting the work done on the
work order or operation.
When a supervisor approves a work order or an operation, the status moves to COMPLETED.
The supervisor can reject an order or operation as part of the review process. If an order or operation is
rejected, the supervisor must specify a rejection reason.
Note
As of the SAP Service and Asset Manager 2205 release, enable and disable parameters are no longer
available through the Parameters tab. You enable or disable all features through the Features tab. See the
Configuring Features [page 73] procedure for details.
Context
1. Maintain assignment type filter WO_ASSIGNMENT_TYPE with only the following assignment types:
Note
You can disable Rule Values 2 and 6 by unchecking the <Active Flag> field to the right of the rule
values if it isn't applicable.
2. Set filter handler /MERP/CL_PM_ORDTYPE_OSTAT_ORU?PM to active, which returns order types that
have overall status profile assigned.
Note
If the default statuses defined in filter handler don't fulfill your business scenario, you can manually add
the system statuses individually to the filter.
Note
If the default statuses defined in filter handler don't fulfill your business scenario, you can manually add
the system statuses individually to the filter.
6. Set SET_INIT_SYS_STATUS filter to disabled. Initial mobile status must be determined based on phase
model overall status.
If the default statuses defined in filter handler don't fulfill your business scenario, you can manually add the
system statuses individually to the filter.
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 SAM2305_NOTIFICATION_GENERIC, 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.
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 SAM2305_NOTIFICATION_GENERIC, and then the Data Filter
tab.
3. Expand the Defined Filters list as follows; Operation - READ Data Distribution and click NOTIF_TYPE.
Click the Change button.
4. Set the /MERP/CL_PM_NOTIFTYP_OSTAT_ORU?PM filter handler to Active. This filter handler returns
notification types that have the overall status profile assigned.
5. Disable the /MERP/CL_PM_NOTIF_TYPE_ORU?PM and /MERP/CL_PM_NOTIF_TYPE_ORU?CS filter
handlers. Notification types returned may not be phase model relevant.
6. Save your changes.
Context
Procedure
Set filter handler /MERP/CL_PM_ORDTYPE_OSTAT_ORU?PM to active, which returns order types that have
overall status profile assigned.
Context
Procedure
2. Configure additional priority type values if notification uses priority type other than PM and SM.
Next: Work Order Partner Determination Procedure oMDO Configuration [page 164]
Context
Procedure
Set filter handler /MERP/CL_PM_ORDTYPE_OSTAT_ORU?PM to active, which returns order types that have
overall status profile assigned.
Context
Procedure
Set filter handler /MERP/CL_PM_NOTIFTYP_OSTAT_ORU?PM is active, which returns notification types that
have overall status profile assigned.
Previous: Work Order Partner Determination Procedure oMDO Configuration [page 164]
Context
Procedure
1. Use EXCL_MOBILE_STATUS_SEQ filter to disable certain phase model status transitions on your mobile
client.
3. Make sure filter handler /MERP/CL_PM_ORDTYPE_OSTAT_ORU?PM is active, which returns order types
that have overall status profile assigned.
The ConfigPanel shows you which PM mobile statuses are mapped to phase model statuses.
From the ConfigPanel home page, navigate to Mobile Application Configuration Mobile Status Setting
tab. Select your application in the Defined Mobile Applications list. Click the Change button to change the
configuration.
The Status Attribute 1 and Status Attribute 2 fields are used for the status mapping as follows:
Note
Set any other statuses not indicated in the following to Disabled when you enable the phase model.
NOTIFICATION STARTED
The status transition of phase model is maintained in IMG Plant Maintenance and Customer Service
Maintenance Service Processing Fiori Apps for Maintenance Processing Configure Overall Status
Profiles .
Note
As of the SAP Service and Asset Manager 2305 release, SAP is adding new state transitions to the mobile
state machine for the supervisor role and the technician role within the maintenance technician persona.
Configure the state transitions (add, remove, activate, or disable) in the state machine for the
corresponding phase model flag. The data filter MOBILE_STATUS_STATE_MACHINE is found in
SAM2305_OVERALL_STATUS.
The state transitions corresponding to the phase model in the state machine are added based on the
phase model state profile from the core configuration. The state machine is the driving factor and
NOT the state transition in IMG ( IMG Plant Maintenance and Customer Service Maintenance
Service Processing Fiori Apps for Maintenance Processing Configure Overall Status Profiles) as of
SSAM2305.
Note
New fields USER_PERSONA, FEATURE_ID and PHASE_MODEL_RELEVANT have been added to the
state machine table to indicate transitions specific to persona, feature and if they are relevant to the
phase model only. For example, the highlighted status transition on the screenshot below allows a
supervisor with a maintenance technician persona to not approve a work order operation in review
status for an order type without a phase model when the PM_SUPERVISOR_PHASE model feature is
enabled.
EAM phase model is added as persona and feature assignment. When phase model is enabled, the following
persona/feature assignment must be enabled. By default, the following setting is inactive:
When EAM_PHASE_MODEL feature is active, phase model-related data is downloaded during synchronization,
for example WorkRequestConsequence or Effect.
Mobile status mapping is still maintained in Configuration Panel with phase model-related statuses disabled in
SAM 2110.
The following mobile status mapping must be active when phase model is disabled:
NOTIFICATION RECEIVED
TASK RECEIVED
WORKORDER HOLD
WORKORDER REJECTED
WORKORDER REVIEW
WORKORDER TRANSFER
WO_OPERATION COMPLETED
WO_OPERATION HOLD
WO_OPERATION RECEIVED
WO_OPERATION REJECTED
WO_OPERATION REVIEW
WO_OPERATION STARTED
WO_OPERATION TRANSFER
Mobile status state machine is added as filter in Overall Status oMDO (SAM2110_OVERALL_STATUS). This
configuration allows us to configure all status transition on mobile client, given the mobile status is already
maintained in the configuration of mobile status mapping.
This new feature is added to support emergency or minor work in a reactive maintenance phase model. It helps
to skip phases and issue a work order or notification when a technician is authorized to create those items.
If the technician is authorized, he will see an option called Minor Work. When this option is selected and the
request is submitted, the request is not sent to the screening technician for approval, but is automatically
approved and is moved to the planning phase.
Note
This feature is available in S/42022, that is, in S4CORE 107 and beyond, as a basic feature.
The process control code can limit a certain process state change based on the system state. It can also
be applied to the execution phase, which prevents the user from moving the order or operation from one
sub-phase to another.
• IMG backend configuration path is the following: IMG Logistics General Product
Lifecycle Management (PLM) Plant Maintenance and Customer Service Maintenance and
Service Processing Fiori Apps for Maintenance Processing General Settings Define Phase
Control Code for Maintenance Orders
• The new feature EAM_PHASE_CONTROL is created to enable the EAM phase control code. To block the
transition of an order or operation from one phase to another when the phase model function is enabled.
If the EAM_PHASE_CONTROL feature is active, the following entities are enabled.
• PhaseControl
• PhaseControlCode
• PhaseControlKey
Note
For this feature to work, the EAM_PHASE_MODEL feature must be active in the SSAM application
configuration.
Note
This feature is available for the S4CORE 106 and subsequent versions.
Geospatial Services provide the technology to create, analyze, maintain, and distribute geospatial data and
information.
You can use either GIS (Geographic Information System) or GEF (Geographical Enablement Framework) with
the app. Note that you can use either service, but you can't use both Services at the same time in the
application.
Note
Esri base maps are the only base maps supported for the app.
A geographic information system (GIS) integrates hardware, software, and data for capturing, managing,
analyzing, and displaying all forms of geographically referenced information.
The SAP Service and Asset Manager application has custom map controls with GIS functionality implemented
using Mobile Development Kit and Open UI extensions. The SAP Service and Asset Manager application is
delivered with predefined globals that are Esri-specific, however, you can point to any GIS vendor you choose.
For information about configuring GEF, see the subtopics located Geographical Enablement Framework (GEF)
[page 186] topic.
Some GIS settings are standard with the initial SAP Service and Asset Manager application.
You can change any of the settings described in this topic to configure the application for your site.
Note
You can also change the map setting metadata through the Mobile Development Kit. Note that if there are
metadata differences, Mobile Development Kit changes override ConfigPanel changes.
In the ConfigPanel, the GISMapParameter entity type contains the following properties:
• ParameterGroup
• ParameterName
• ParentParameterGroup
• ParameterValue
Use the fields in the following section to properly categorize these parameters.
From the ConfigPanel Home page, navigate to OData Mobile Data Object Configuration Data Filter Tab
<APP_VERSION>_GIS_MAP_CONTROL Operation - READ Data Distribution . Click the Change button.
See the following for an example screenshot of the parameters in the ConfigPanel in the Data Filter tab, and a
table representing how to configure the parameters in the tab.
Parent Parameter
Parameter Group Parameter Name Parameter Value Group Description
Note
For more informa-
tion about how
to get license
to ESRI ClientID,
see ArcGIS Devel-
opers documenta-
tion .
Note
You can maintain either the SPATIAL_OBJECTID field or the SPATIAL_GUID field, or both. However, it is
recommended that you maintain the SPATIAL_OBJECTID field.
Use
You can view token-based authenticated basemaps and feature layers on the mobile client. Use the
ConfigPanel to configure the client ID and client secret strings.
The mobile client retrieves the tokens. The client ID and client secret are supplied to the client so each client
can generate their tokens for accessing authenticated services.
If your organization wishes to access Esri application-level authenticated GIS services, configure the SAP
Service and Asset Manager application as shown in the following procedure.
You can also configure a proxy through Esri. Authenticated basemaps and feature layers are requested through
a local proxy. The proxy manages the generation and use of tokens based on the client ID and client secret. For
more information on configuring a proxy, see the Esri documentation, Working with Proxy Services .
To turn on GIS authenticated services in the ConfigPanel, add the following rule:
1. From the ConfigPanel Home page, navigate to OData Mobile Data Configuration OData Mobile
Data Object List Data Filter Tab SAP_ASSET_MANAGER_<XX> SAM2305_GIS_MAP_CONTROL
Operation - READ Data Distribution INI_PARAMETER .
2. Click the Change button. In the Rule List section, click the Add button to add a new rule. The rule gives you
the freedom to retrieve your client credentials in a manner appropriate for your organization:
• Parameter Group: AUTHENTICATION
• Parameter Name: ConfigRule
Sample Code
{
"ClientId": "YourClientId",
"ClientSecret": "YourClientSecret"
}
Establish an oAuth connection using a secure TokenID to request offline maps information from the ArcGIS
server.
Context
The oAuth 2.0 client ID and secret for your connection are stored in the RFC destination. Maintain the RFC
destination in the app parameters in the ConfigPanel.
See the following screenshot for the parameter that is included in the out of the box SAP Service and Asset
Manager application:
Procedure
1. Using the SAP GUI enter transaction SM59 and enter ARCGIS_CONNECTION_TOKEN_URL, the new RFC
destination.
2. From the Technical Settings tab of your new RFC connection, set the Target Host to match the ArcGIS
server URL. Find the information for the Target Host field in the Service Host field on the General
Data tab of the Geospatial Service Definitions page in the ConfigPortal. Set the Path Prefix to /sharing/
rest/oauth2/token?.
Note
3. If necessary, configure the proxy that you're using to allow your back end systems to connect to the
internet.
Create a new rule in the SAP Service and Asset Manager metadata to retrieve a valid authentication token for
authenticated resources within the map control.
Context
To create a new rule for offline GIS, see the existing rule found in the metadata file of SAP Service and
Asset Manager at /SAPAssetManager/Rules/Extensions/[Link]. The rule found there uses
an online oData request to get the token from the back-end server. This rule is the recommended way to
retrieve a token from the Esri oAuth service.
1. Navigate to the metadata of your SAP Service and Asset Manager project using your preferred text editor
or the SAP Web IDE and create a new rule.
2. Save the rule you created.
3. Open the .page file that contains your map control using your preferred text editor.
4. Navigate to the Controls section and locate the control for the map. The map control has the following
specific properties:
• Type of [Link]
• Module of Extension-MapFramework
5. Add a TokenAuthentication object within the ExtensionProperties object of the control. Add an Action
property of a rule to retrieve a valid authentication token as shown in the following example:
Sample Code
{
"_Type":"[Link]",
"Module": "extension-MapFramework",
"Control":"MapExtensionWithContext",
"Class":"MapExtensionWithContext",
"_Name":"MapExtensionControl",
"ExtensionProperties": {
…
"TokenAuthentication": {
"Action": "/path/to/rule/that/returns/a/
token"
},
…
}
}
6. Save the page and update your application with the new metadata.
Results
The new metadata allows token authentication on your ArcGIS map when required.
Geographical Enablement Framework (GEF) works as the foundation to extend business data with geometric
attributes for SAP S/4HANA. GEF is integrated directly into your SAP S/4HANA system.
As a framework leveraging the spatial capabilities inherent on the SAP S/4HANA platform, it enables
organizations to develop geospatially enriched business data, and make them accessible from within SAP
Service and Asset Manager.
SAP Service and Asset Manager uses the geometries (points, lines, and polygons) from the GEF geotables
stored in SAP S/4HANA for the geo-enabled objects in the application. SAP Service and Asset Manager also
Note
Esri base maps are the only base maps supported for the app.
For detailed information about GEF, including installation and implementation procedures, see the
Geographical Enablement Framework documentation.
For information about configuring GIS, see the subtopics located in the Geographic Information System (GIS)
[page 178] topic.
SAP Service and Asset Manager utilizes GEF by default. When implementing GEF, ensure that GIS is disabled in
the ConfigPanel.
1. From the ConfigPanel home page, navigate to Geospatial Service Definitions. Select your application
release using the Mobile Application Filter. Expand the Geospatial Mobile Services by App tree in the left
panel.
2. Uncheck the Active boxes from the following services:
• <APPXX>_GIS_QUERY_EQUIPMENT
• <APPXX>_GIS_QUERY_FLOC
• <APPXX>_GIS_QUERY_NOTIFICATION
• <APPXX>_GIS_QUERY_WORKORDER
3.
4.
Some GEF settings are standard with the initial SAP Service and Asset Manager application.
You can change any of the settings described in this topic to configure the application for your site.
Note
You can also change the map setting metadata through the Mobile Development Kit. Note that if there are
metadata differences, Mobile Development Kit changes override ConfigPanel changes.
Before enabling GEF, deactivate GIS if you previously had it activated. See the Disabling GIS [page 187] topic for
more information.
1. From the ConfigPanel home page, navigate to Geospatial Service Definitions. Select your application
release using the Mobile Application Filter. Expand the Geospatial Mobile Services by App tree in the left
panel.
2. Check the Active boxes from the following services:
• <APPXX>_GEF_QUERY_EQUIPMENT
• <APPXX>_GEF_QUERY_FLOC
• <APPXX>_GEF_QUERY_NOTIFICATION
• <APPXX>_GEF_QUERY_WORKORDER
Note
If you are using custom GEF services, enable those rather than the standard GEF services.
If you've mapped a custom business object to a GEF scenario using SPRO in the SAP GUI, you must also map
the connection in the Config Panel.
1. From the Config Panel home screen, navigate to Geospatial Service Definitions Parameter Settings
tab . Select your application release, then select the GEF service you've customized in the Geospatial
Services by Mobile App list.
2. Click the Change button.
3. In the Operation Parameter Settings section, navigate to Parameters for Service Operation Provider
Operation - QUERY Standard Parameter Parameter - EAM Scenario .
4. In the Value Setting section, change the Parameter Value to your custom business object.
5. Save your changes.
1. From the ConfigPanel Home page, navigate to OData Mobile Data Object Configuration Data Filter
Tab <SAMXX>_GIS_OBJECT_DATA Operation - READ Standard Filter GEOSERVICE_ID . Click the
Change button.
Ensure that any GIS objects are inactive. Ensure that the following objects are active:
• <APPXX>_GEF_QUERY_EQUIPMENT
• <APPXX>_GEF_QUERY_FLOC
• <APPXX>_GEF_QUERY_NOTIFICATION
• <APPXX>_GEF_QUERY_WORKORDER
If you have any custom OMDOs for GEF, enable those. If you have any custom OMDOs for GEF, enable
those, rather than the standard GEF OMDOs.
2. While still on the Data Filter tab with the <SAMXX>_GIS_OBJECT_DATA selected, navigate to Operation -
READ Data Distribution GIS_ASSIGNMENT_TYPE .
Ensure the Range Value is set to 2 - GEF Integration.
3. By default, all basemaps are maintained. GEF uses information coming from SAP S/4HANA GEF APIs.
When you activate GEF, all GIS configuration is invalid. Configure the following parameters for GEF:
While still on the Data Filter tab, navigate to <SAMXX>_GIS_MAP_CONTROL Operation - READ Data
Distribution INI_PARAMETER .
Ensure that the following parameters found in the CONFIG parameter group are configured for GEF:
• GefUIProfileID: Standard configuration is EAMALL. If you've customized this in the SAP GUI, select
your customization.
• EnableGef: Set to True
You can configure the number of business objects with geometry information displayed per page.
Procedure
1. Navigate to metadata/definitions/Pages/Extensions/[Link].
2. Change 100 to the number of business objects displayed per page as shown in the following example:
Sample Code
"Controls": [
"ExtensionProperties": {
"ItemsPerPage": 100,
SAP Service and Asset Manager supports GEF geometry download as well as GEF create and update.
Context
• Create: Supports the ability to create GEF point, line, and poly-line directly from the map and from the
MAIF /MERP/CL_CORE_GIS_GEOSERV_GEF object handler.
• Update: Supports the ability to update GEF point, line, and poly-line directly from the map and from the
MAIF /MERP/CL_CORE_GIS_GEOSERV_GEF object handler.
Note
The update feature supports the ability to update a time-sensitive GEF coordinate. Currently, the create
feature does not support time-sensitive geometry.
Procedure
1. In the ConfigPanel, navigate to the OData Mobile Data Object Configuration section and find OMDO
SAM2305_GIS_OBJECT_DATA. Click the Data Filter tab.
2. Click the Change button.
3. Expand the Defined Filters list to show and change the following .
Context
Note
Push configuration is available for SAP Service and Asset Manager for Android starting with the 4.0 release.
Event-based push is supported for assignment types 1 (header-level person responsible for the work order)
and 2 (operation-level personnel number of the work order). You can only configure push for one work order
assignment type at a time.
By default, work order push is enabled for whichever assignment type your work order OMDO is set to. You
can manually assign the WO_ASSIGNMENT_TYPE filter for your data distribution model to 1 or 2 to set a push
assignment type different to the assignment type of the work order data distribution.
Procedure
1. In the ConfigPanel, navigate to the OData Mobile Data Object Configuration section and find OMDO
SAM2305_WORK_ORDER_GENERIC. Ensure the filter WO_ASSIGNMENT_TYPE is set to 1 on the Data
Filter tab.
2. Return to the Home page of the ConfigPanel. Click the Push Scenario Definition link. Ensure that your
mobileapplication is selected in the Mobile Application Filter.
3. Ensure the Active flag for the SAM2305_EMERGENCY_WORKORDER_PUSH scenario on the General Data
tab is checked. Note that you can have both work order and notification pushes marked as Active because
they are separate objects.
4. Make sure the configuration in the Source Setting and Distribution Setting sections are correct.
By default, the <Source Object> for the work order operation push is the exchange object
SAM2305_WORK_ORDER_PUSH with the <Distribution Object> SAM2305_WORKORDER_PUSH.
Context
Note
Push configuration is available for SAP Service and Asset Manager for Android starting with the 4.0 release.
Event-based push is supported for assignment types 1 (header-level person responsible for the work order)
and 2 (operation-level personnel number of the work order). You can only configure push for one work order
assignment type at a time.
By default, work order push is enabled for whichever assignment type your work order OMDO is set to. You
can manually assign the WO_ASSIGNMENT_TYPE filter for your data distribution model to 1 or 2 to set a push
assignment type different to the assignment type of the work order data distribution.
Procedure
1. In the ConfigPanel, navigate to the OData Mobile Data Object Configuration section and find OMDO
SAM2305_WORK_ORDER_GENERIC. Ensure the filter WO_ASSIGNMENT_TYPE is set to 2 on the Data
Filter tab.
Context
Event-based push is supported for notification assignment types 1 through 5. You can only configure push for
one notification assignment type at a time.
By default, notification push is enabled for whichever assignment type your notification OMDO is set to. You
can manually assign the NOTIF_ASSIGNMENT_TYPE filter for your data distribution model to 1, 2, 3, 4 or 5 to
set a push assignment type different to the assignment type of the notification data distribution.
1. In the ConfigPanel, navigate to the OData Mobile Data Object Configuration section and find
OMDO SAM2305_NOTIFICATION_GENERIC. Ensure the filter NOTIF_ASSIGNMENT_TYPE is set to the
assignment type of your choice (1 - 5) on the Data Filter tab.
2. Return to the Home page of the ConfigPanel. Click the Push Scenario Definition link. Ensure that your
mobile application is selected in the Mobile Application Filter.
3. Ensure the Active flag for the SAM2305_EMERGENCY_NOTIFICATION_PUSH scenario on the General
Data tab is checked. Note that you can have both work order and notification pushes marked as Active
because they are separate objects.
4. Make sure the configuration in the Source Setting and Distribution Setting sections are correct. By default,
the <Source Object> for the notification push is the exchange object SAM2305_NOTIFICATION_PUSH
with the <Distribution Object> SAM2305_NOTIFICATION_PUSH.
5. Return to the ConfigPanel Home page, then navigate to the EFI Assignment section. In the Enhancement
Implementation Includes list, select /MERP/EFI_PM /MERP/CL_PM_QMNUM_EFI_EVT .
6. Click the Assignment tab. Ensure the Active checkbox is checked for the exchange object
SAM2305_NOTIFICATION_PUSH.
Context
Note
Push configuration is available for SAP Service and Asset Manager for Android starting with the 4.0 release.
1. From the ConfigPanel Home page, navigate to the Outbound Trigger Configuration section and select your
desired mobile application from the Mobile Application Filter dropdown menu at the top of the page.
2. From the Outbound Triggers by Mobile App list, select the outbound trigger
SAM2305_WORKORDER_TRIGGER_SCPMS. Make sure that the <Cloud Platform Mobile App ID>
matches your mobile services application ID from SAP Business Technology Platform Mobile Services. By
default, the application ID is set to [Link].<appXX>.[Link].
3. Set up the RFC destination SAM2305_SCPMS_PUSH_NOTIFICATION pointing to the mobile services host
name using the SAP GUI:
a. In the SAP GUI, using transaction SM59, add the following new RFC destination:
SAM2305_SCPMS_PUSH_NOTIFICATION of type G (HTTP Connection to External Serv)
b. On the Technical Settings tab of the new connection, set the Target Host to match the push API of
the SAP Business Technology Platform Mobile Services. Use service number 443, which is the port
number of the HTTPS connections.
Note
If necessary, configure the proxy that you are using to allow your back-end systems to connect to
the Internet.
Note
On the first delta sync, the SAP Service and Asset Manager client automatically performs substeps a-d
for you. If desired, you can still perform these substeps to verify that the push registration process has
completed successfully.
a. Using the SAP GUI, launch the Admin portal with transaction code /n/SYCLO/ADMIN. On the Admin
portal home page, select Administration User Management . Make sure to select your desired
mobile application in the Mobile Application Filter field at the top of the page. Choose Search to list all
users for that application.
b. Select User ID under Search Result, and click the Client Registration Info tab under the Mobile User
Detail section. Choose Change from the menu bar.
c. Enter the matching CPms User Id (using upper case) for the back end user name listed under this tab.
d. Save your changes.
7. Return to the Home page of the ConfigPanel. Select the Push Scenario Definition page. Under Push
Scenarios by Mobile App list, select the desired push scenario definition. Click the Outbound Trigger tab
and ensure that the proper outbound trigger is assigned and active for the push scenario.
Prerequisites
Note
The SAP Service and Asset Manager Installation Guide is a guide to setting up the basic framework
necessary for push services using the default settings. For more details regarding configuration of push
services, see the Push Scenario Definition [page 53] topic.
• SAP Service and Asset Manager application on the device is running on Mobile Development Kit 2.2.001
• You have installed SAP Service and Asset Manager 2305
• You have installed either SAP Mobile Add-On ECC or SAP Mobile Add-On for SAP S/4HANA. See the
following installation guides on the following portal pages for version information:
• SAP S/4HANA Mobile Add-On
• SAP Mobile Add-On ECC
Context
To configure and activate push for the Android platform, see the Configuring Push for Android [page 214]
procedure.
Procedure
1. Configure the SAP Business Technology Platform Mobile Services push API:
a. Enable the Push Notification feature in SAP BTP services:
c. If you are using a custom deployment of SAP Service and Asset Manager, upload the corresponding
APNs certificates here. If you are using the default application provided by the Apple App or the
Google Play store, select Predefined for SAP Service and Asset Manager in the Predefined Global Push
Configuration section.
The SAP Business Technology Platform Mobile Services is configured for push.
2. Configure the back-end system to utilize the SAP BTP services push APIs:
b. In the Technical Settings and tab of the new connection, set the Target Host to match the push API of
the SAP BTP services, using 443 (the port number for HTTPS connections).
If necessary, configure the proxy you are using to allow your back end to connect to the outside
internet.
c. Click the Logon & Security tab. Under the Logon Procedure, select Basic Authentication. Enter the user
name and password of a service user.
d. In SAP Business Technology Platform, ensure your service user has the role of Notification User
assigned to them to ensure that the user is allowed to utilize the SAP BTP services API. The service
user must be a member of the SAP Business Technology Platform account.
e. In the Security Options section of the Logon & Security tab, ensure that the <SSL Secure Protocol>
is set to Active.
f. Remaining in the Security Options section, ensure that the SSL Certificate List used contains the SAP
Business Technology Platform certificate chain and is active.
g. Save the connection and perform a connection test. If the configuration is completed properly, a 200
HTTP response is returned.
b. Click the Parameters tab. If your user store on the back end and user store on the SAP Business
Technology Platform are identical, set the SCPMS_WITH_SAP_USER_ID parameter value to True. If the
user stores are not identical, set the parameter to False.
c. Return to the ConfigPanel home screen and click the Push Scenario Definition link. Navigate to the
Outbound Trigger tab. Find and highlight the push on the list of Push Scenarios by Mobile App and
ensure that the outbound trigger is active.
Results
Push services are activated for SAP Service and Asset Manager. Thoroughly test the push functionality before
deploying to the client devices.
Note
The SAP Service and Asset Manager Installation Guide is a guide to setting up the basic framework
necessary for push services using the default settings. For more details regarding configuration of push
services, see the Push Scenario Definition [page 53] topic.
• SAP Service and Asset Manager application on the device is running on Mobile Development Kit 2.2.001
• You have installed SAP Service and Asset Manager 2305
• You have installed either SAP Mobile Add-On ECC or SAP Mobile Add-On for SAP S/4HANA. See the
following installation guides on the following portal pages for version information:
• SAP S/4HANA Mobile Add-On
• SAP Mobile Add-On ECC
Context
To configure and activate push for the Android platform, see the Configuring Push for Android [page 214]
procedure.
Procedure
1. Configure the SAP Business Technology Platform Mobile Services push API:
a. Enable the Push Notification feature in SAP BTP services:
c. If you are using a custom deployment of SAP Service and Asset Manager, upload the corresponding
APNs certificates here. If you are using the default application provided by the Apple App or the
Google Play store, select Predefined for SAP Service and Asset Manager in the Predefined Global Push
Configuration section.
The SAP Business Technology Platform Mobile Services is configured for push.
2. Configure the back-end system to utilize the SAP BTP services push APIs:
a. Using the SAP GUI, run transaction SM59. Create a new HTTP connection with the name
SAM2305_SCPMS_PUSH_NOTIFICATION.
Note
In a Cloud Foundry environment, you must use email instead of an I-number to utilize push
notifications in the Administration portal.
If necessary, configure the proxy you are using to allow your back end to connect to the outside
internet.
c. Click the Logon & Security tab. Under the Logon Procedure, select Basic Authentication. Enter the
Mobile Push Notification Alias as the user name and the Mobile Push Notification API Key as the
password.
d. In Mobile Services, ensure your service user has the API Key assigned to them to ensure that the user
is allowed to utilize the SAP BTP services API. This API key is the same value used as the password in
the RFC Destination.
Basic authentication for this service user allows for free communication flow.
e. In the Security Options section of the Logon & Security tab, ensure that the <SSL Secure Protocol>
is set to Active.
f. Remaining in the Security Options section, ensure that the SSL Certificate List used contains the SAP
Business Technology Platform certificate chain and is active.
g. Save the connection and perform a connection test. If the configuration is completed properly, a 405
code is returned.
j. On the additional properties tab, create a new property with the following attributes:
• Property Group: PUSH
• Property Name: X-API-Key
• Property Value: Mobile push API key from SAP BTP services
b. Click the Parameters tab. If your user store on the back end and user store on the SAP Business
Technology Platform are identical, set the SCPMS_WITH_SAP_USER_ID parameter value to True. If the
user stores are not identical, set the parameter to False.
Results
Push services are activated for SAP Service and Asset Manager. Thoroughly test the push functionality before
deploying to the client devices.
Firebase Cloud Messaging (FCM) is a cross-platform cloud solution for messages and notifications for Android,
iOS, and web applications.
Context
To enable push notification for the SAP Service and Asset Manager application using the Android platform, use
the following procedure:
Procedure
1. Create a free Firebase account. See the main Firebase page to set up a new account, or connect an
existing account.
Note
4. Copy and paste the information in the Server Key field to use in a later step.
Your app is registered and you’re moved to Step 2 - Download config file.
For instructions on how to enable Android push notifications in SAP BTP services, see the Android Push
Notifications procedure.
For detailed information on configuring push for the SAP Service and Asset Manager application, see the
procedure Activating Default Push Services for SAP Asset Manager, specifically the screenshot in Step 1d.
Next Steps
Continue to the procedure Setting up the Outbound Trigger for your Push Configuration [page 194].
[Link]
[Link]
For OData troubleshooting information, see OData API in the SAP Cloud Integration 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 Asset 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 relevant OData services (/MERP/SAP_CREW_MANAGER_<XX> and /MERP/
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 221]
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 221]
• Setting the OData Mobile Data Object Configuration [page 223]
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 Asset 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 Asset 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.
Use parameters to enable the checklist feature and configure other checklist options available.
Context
Note
As of the SAP Service and Asset Manager 2205 release, enable and disable parameters are no longer
available through the Parameters tab. You enable or disable all features through the Features tab. See the
Configuring Features [page 73] procedure for details.
The ASPM Checklist feature is called IAM_CHECKLIST. By default, the feature is not enabled.
To configure the checklist options for SAP Service and Asset Manager, use the CHECKLISTS parameter group
and the following parameters within the group:
• MobileStatusCompleted: Default is Completed. Do not change this setting unless you are integrating SAP
Service and Asset Manager with another product besides ASPM.
• MobileStatusInProgress: Default is In Progress
• MobileStatusOpen: Default is Open
• CompletedStatusText: Default is Published. This parameter is used to distinguish completed checklists
that have been downloaded from the back end versus checklists that have been completed locally on
the client but are not yet synced. The parameter is necessary to make logic decisions on the client as
checklists that have been completed and synced to the back end are no longer allowed to be edited. Do
not change this setting unless you are integrating SAP Service and Asset Manager with another product
besides ASPM.
The CHECKLISTS parameters correspond to the rules found in the OData mobile data object
SAM2305_ASPM_CHECKLIST. You can add a 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.
Results
Next Steps
Continue to the following procedures to finish configuring the checklist feature for ASPM:
• Setting Up an ASPM Connection to the ASPM System to Use Checklists [page 233]
• Checking the Readiness of the ASPM System [page 236]
• Readiness Check for Authenticated GIS Maps [page 241]
The RFC destination is already created and connected to the ASPM out of box. However, an oAuth connection
from the ASPM Cloud Foundry system to SAP Service and Asset Manager is required.
Prerequisites
Use the Integration of Asset Central Foundation with SAP EAM guide to establish an oAuth connection. Pay
attention to the Server Management Properties topic.
Context
Use the following procedure to create and configure an oAuth connection from the ASPM Cloud Foundry
system to SAP Service and Asset Manager.
Procedure
Note
Before following the instructions in this topic, ensure that you’ve performed the Setting Up an ASPM
Connection to the ASPM System to Use Checklists [page 233] procedure.
The readiness check program checks your set-up (performed in the Setting Up an ASPM Connection to the
ASPM System to Use Checklists [page 233] procedure), such as the system component. If your configuration
has an error, a red light displays on the output that isn't set up properly. The /syclo/admin set-up is also
completed you've selected certain options listed in this topic.
Using the SAP GUI, execute the program /MERP/CORE_READINESS_CHK_PROG to run the readiness check.
The selections you make in this procedure are all found in the main Middleware server management - ASPM
section. See the Readiness Check for Authenticated GIS Maps [page 241] procedure for details on the GIS
Offline Maps section.
The readiness check program gives 3 options to check or complete the ASPM checklist for SAP Service and
Asset Manager:
This checkbox disables the rest of the inputs on the screen if checked. Choosing this option runs the program
in check-only mode. No RFC destination or configuration is made. Select this option if you've performed all
the steps in Setting Up an ASPM Connection to the ASPM System to Use Checklists [page 233]. Running the
readiness check only confirms that no steps were missed. If there are errors in your set-up, a red light displays
by the output. You can then use the transaction code for that output to fix the issue.
Output
In the following sample screenshot, the red light result means that the RFC connection test used to set up the
ASPM checklist feature has failed the connection test. To fix:
Use this checkbox to reuse the ACI app if it exists. Selecting this option uses the same RFC destination and
authentication properties to create a new server configuration.
Input
Use this option if Step 3d wasn't completed in the Setting Up an ASPM Connection to the ASPM System to
Use Checklists [page 233] procedure and you want to result the RFC destination used for ACI configuration to
complete the set-up .
This option uses the ACI middleware configuration to create the ASPM_CLOUD server configuration for SAP
Service and Asset Manager. If ACI configuration doesn’t exist, use the Input RFC Destination option to create
the configuration.
The red light shown in the following example screenshot shows the error thrown when there's no ACI
configuration in the customer system to reuse. If a red light is displayed, complete the set-up, then run the
check program in reuse mode to complete the ASPM checklist set.
Create the RFC destination or middleware server configuration: Using the RFC Destination section, give
an RFC Destination, select an oAuth Method and oAuth Value. An RFC destination and/or middleware server
configuration is created if they don't already exist.
Use this option if Step 3d wasn't completed in the Setting Up an ASPM Connection to the ASPM System to
Use Checklists [page 233] procedure and you want to complete the rest of the set-up-up, along with the RFC
destination creation. Once the destination is created, or if the destination exists, but the ASPM feature set up
in /SYCLO/ADMIN doesn't exist, this program completes the set-up with the RFC destination.
Note
For SAP_BASIS release 752 and above, use the radio button oAuth Profile and property
AUTH_OAUTH_PROFILE. For earlier versions, use the radio button oAuth RFC and property
AUTH_OAUTH_RFC.
Input
Output
Troubleshooting
If the output of the readiness check shows the RFC connection test failed, perform a manual test. Make sure to
add a proxy and/or certificate to STRUST if needed.
You can manually change the middleware server configuration via /SYCLO/ADMIN.
Next Steps
If you’re using SAP Service and Asset Manager with authenticated GIS, continue to the Readiness Check for
Authenticated GIS Maps [page 241] topic.
Context
Note
Before performing this procedure, follow the appropriate ASPM readiness check. See the Checking the
Readiness of the ASPM System [page 236] topic for details.
Procedure
2. Create the RFC Destination: Creating the RFC destination stores the GIS server login credentials and adds
them to the mobile application parameter.
The /SYCLO/ADMIN ConfigPanel entry the Authenticated GIS readiness check program checks or creates
is shown in the following example:
SAP Service and Asset Manager for Field Operations Worker uses the digital core with SAP S/4HANA for task
driven activities and rounds. It supports workers who perform asset inspections and checks with focus on
measurement points and on smaller services and repairs.
Field Operations Worker, or FOW, is an add-on component to SAP Service and Asset Manager. If you don’t
see FOW features while using the SAP Service and Asset Manager application, or in the ConfigPanel, your site
hasn’t installed the component.
Field Operations Worker adds the following functionality to the core SAP Service and Asset Manager
application:
• View routes data: A route is comparable to a work order in the base SAP Service and Asset Manager
application.
• View stops data: A stop in Field Operations Worker is comparable to an operation in the base SAP Service
and Asset Manager application. A route is composed of one or more stops.
• View asset information: An asset in Field Operations Worker is comparable to a piece of equipment in the
base SAP Service and Asset Manager application. Assets are located at an FOW stop.
• Use field data capture to take readings on measurement points. Measurement points are located on assets
or a set of assets at a route stop.
Creating rules based on order types affects synchronization processing and order downloads to the mobile
devices of your users who use the Field Operations Worker component.
Prerequisites
• The order types for work orders that are downloaded to technicians using the Field Operations Worker
component are already determined.
• The person performing the procedure has access to the Config Panel and permissions to change settings.
Note
Field Operations Worker orders are a subset of the base SAP Service and Asset Manager application work
orders.
The following procedure modifies the synchronizing behavior of the SAP Service and Asset Manager
application, along with the Field Operations Worker component. After you complete the procedure, only orders
with a given order type of PM02 are downloaded to the FOW component. In the procedure, you change the
ORDER_TYPE filter in the OMDOs involved in order synchronization. Specifically, you add a rule to the filter in
the SAM2305_ROUTE OMDO to include only the desired order type.
If you don’t create a rule for the PM02 order type, then that order type is excluded from work order download
synchronization processing. If the FOW orders are excluded from synchronization processing, then the orders
aren’t present on the mobile clients of your users.
Procedure
1. Click the OData Mobile Data Object Configuration link, then click the Data Filter tab from the main
ConfigPanel page. Be sure to have your desired mobile application chosen in the Mobile Application Filter
field at the top of the page.
Selecting an application filters the OData Mobile Data Object by Mobile App choices in the left panel with
only OMDOs available in your application.
2. Expand the OData Mobile Data Object by Mobile App list on the left and click SAM2305_ROUTE.
3. Select the Data Filter tab.
4. Click the Operation - READ Data Distribution ORDER_TYPE node in the Defined Filters list.
5. Create a rule using the following parameters if the rule doesn’t already exist:
• DOF Rule Type: Static Value in Range Format
• Sign: Inclusive
• Option: =
• Low Value: PM02 - Maintenance order
• Ensure the Active Flag box is checked
Results
After you finish the procedure, both Field Operations Worker orders and base SAP Service and Asset Manager
work orders are downloaded by the SAP Service and Asset Manager application.
There are a few guidelines that must be applied to the SAP system for the user to be able to use the safety
technician persona:
Context
Procedure
1. In the SAP GUI, navigate to the /n/syclo/configpanel transaction to open the syclo configuration
panel.
2. Under oData Channel Integration Settings, navigate to oData Mobile Data Configuration.
3. By selecting the oMdo required, you will find the filters in the Data Filter section.
Assignment types
The following work permit assignment types (same for safety certificates) are supported:
• 1: User Plant (the user must add the IWK user parameter)
• 2: User Work Center (the user must add the VAP user parameter)
• 3: User Planner Group (the user must have the IHG user parameter setup)
• 4: Partner Function
• D: Dependency queue
• Z: Other (implement BADI)
1. On the SAP GUI, navigate to the SU3 transaction and select the Parameters tab.
2. Add a user parameter identifier with the value.
It is possible to disable or enable sampling of some entities if required. For example, you can disable
WCMApplicationLongtext, WCMApplicationAttachments and other such entities.
Use specific mobile app settings to get some entities disappear and make the signature optional. You can
change these settings on the Mobile App Configuration page.
1. Navigate to the Syclo ConfigPanel and then select Mobile Application Configuration
2. Navigate to Mobile App and then select the Parameters tab.
The possible values for safety technician persona are as follows (see figure below):
7.4 xChange
With the exchange framework, we also provide exchange detection. The exchange framework allows users to
capture changes made in the backend to WCM objects. This is also highly customizable. You can choose which
fields you want to check, and you can also enter data filters.
To access the xChange field detection and select specific fields of the object:
You can create and configure the usage types. There are several customization options, the most important of
which is Operation Cycle - Specification.
A new release related to the safety technician persona is that work orders can be dependent objects. This
means that if the persona is enabled, you have the ability to load work orders that are associated with the
related work permits.
Note
In this release, only assignments at the work order header level are supported for the safety technician
persona. Operation level assignments will be supported in a later version.
The Field Service Management solution connects and enables operations while simplifying and automating
processes, helping to accelerate execution, improve the productivity of service teams, and control costs.
Using the Field Service Management solution, field service leaders and managers can make decisions based on
real-time insights, gain visibility of field service operations, and take advantage of analytical dashboards.
Field service technicians using the SAP Service and Asset Manager app get assignment information in
advance, so they are better prepared. Flexible mobile tools, including guided procedures and checklists help
solve issues on the first visit while reducing time spent on administrative tasks. While on-site, technicians can
collect relevant information about the assignment, get customer signatures, and sync information and back
office processes quickly.
Field Service Management planning board administrators can use geolocation information from the mobile app
to enable scheduling and dispatching based on the location of the technician.
Supported Scenarios
The following scenarios are supported for the integration of SAP Service and Asset Manager with Field Service
Management Scheduling:
• Status updates: Status updates from SAP Service and Asset Manager are propagated to the Field Service
Management Planning and Dispatching Tool. Since Field Service Management supports only activity level
assignments, status transition is only supported for the Assignment Type 2 – Operation Level Assignment
to Personnel Number. Only statuses assigned to the Field Service Management service workflow statuses
are propagated to Field Service Management.
• Technician Location Tracking: The location of the technician captured from SAP Service and Asset
Manager is updated to Field Service Management so that it can be viewed in the Field Service Management
service map.
• Reject Operation: If a technician rejects an operation, the corresponding activity in Field Service
Management is unassigned.
• Transfer Operation: If a technician transfers an operation from one technician to another, the
corresponding activity in Field Service Management is reassigned from one technician to another.
The location updates from the client can be viewed under the Field Service Management Map, Planning and
Dispatch Service Map .
It is assumed that the Proaxia Field Service Management connector is configured and set up to replicate the
data between the SAP back end and the SAP Field Service Management system.
SAP Service and Asset Manager integration with Field Service Management requires that the following
scenarios are configured and enabled within the Proaxia Field Service Management connector:
• Employees: Replicate employees (SAP HR Personnel numbers) from SAP ECC to Field Service
Management as Persons. Use transaction PA30 to configure Infotype 0105/001 to map the user name
to the user’s personnel number replicated in Field Service Management.
• Materials: Replicate Materials in the back end as Items to Field Service Management. Items are needed to
create equipment.
• Equipment / Functional Locations: Replicate Equipment and/or Functional Location to Field Service
Management as Equipment. Equipment are technical objects assigned to service orders
• Customers: Replicate Customers to Field Service Management as Business Partners. Business partners
are assigned to service orders.
• Business Partners (Optional): Replicate Business Partners to Field Service Management if they're needed
in the customer scenario as part of order processing.
• Orders: Replicate Service Orders, Work Orders, and Operations to Field Service Management.
• Assignments (Field Service Management): Replicate Assignments from the Field Service Management
system to the back end.
To execute the supported integration scenarios between SAP Service and Asset Manager and Field Service
Management, SAP Service and Asset Manager integrates directly with Field Service Management using the
Service and Data APIs provided by Field Service Management. However, the underlying objects that need to
be updated (service orders (service calls in Field Service Management), operations (activities in Field Service
Management), employees (persons in Field Service Management)), are created by the Proaxia connector.
Therefore, you must implement the following prerequisites for the end-to-end scenarios to work:
• Switching on Sending externalID from the Proaxia Field Service Management Connector to the Field
Service Management Solution [page 254]
• Implement BADI Methods [page 255]
Context
Note
Perform these changes within the configuration of the Proaxia Field Service Management connector.
Procedure
Switch on the sending of the externalId from the Field Service Management connector to Field Service
Management as shown in the following screenshots:
Context
Depending on the integration framework used, implement the /MERP/CA_FSM_CROSSREF_BADI BADI. The
methods in the BADI must return the cross-referencing information between the back end object ID and the
Field Service Management object ID.
Procedure
1. Implement the local method to determine the company ID, required for the GET_EMPLOYEE_IDS BADI
method.
METHOD get_compid.
lv_account = iv_account.
lv_fsmaccount = lv_string1.
lv_fsmcompany = lv_string2.
ls_cacc = /pacg/ecm_cl_d_access=>get_cloudcomp_definition(
rv_compid = ls_cacc-compid.
ENDMETHOD
This method is a prerequisite for saving geolocations captured from SAP Service and Asset Manager to the
Field Service Management planning and scheduling board.
The method must return the Field Service Management internal employee ID(s) (Field id of the Field
Service Management Person entity) based on the personnel number(s) provided.
Use the importing parameter IO_ACI_SERVICE to execute a service call to Field Service Management for
retrieving the id based on the code in the following code example.
Note
For simplicity, it is assumed that only a single personnel number is passed as a parameter. Adjust the
code accordingly to handle multiple parameters. The following code is an example. You may need to
make additional adjustments for your environment.
METHOD /merp/if_ca_fsm_crossref_badi~get_employee_ids.
DATA:
lv_pernr_query TYPE string,
ls_oblnk TYPE /smfnd/sync_d_oblnk_h_upd_str,
lv_id TYPE /smfnd/sync_object_key_dte,
lv_url TYPE string,
lv_char_code TYPE n LENGTH 3,
lt_persondata TYPE STANDARD TABLE OF ty_persondata,
ls_persondata LIKE LINE OF lt_persondata,
lt_error TYPE STANDARD TABLE OF ty_error,
ls_error LIKE LINE OF lt_error,
lv_status_code TYPE i,
lv_reason TYPE string,
lv_result TYPE string,
lv_raw_data TYPE xstring,
lv_compid TYPE /pacg/ecm_compid,
lv_cloud_uname TYPE /pacg/ecm_cloud_uname,
ls_pernr LIKE LINE OF it_pernr.
IF io_aci_service IS BOUND.
CLEAR lv_pernr_query.
lv_char_code = lv_status_code.
IF lv_char_code CP '4*'.
ls_error-error = lv_result.
APPEND ls_error TO lt_error.
ELSE.
/aci/
cl_util_json_handler=>deserialize( EXPORTING json = lv_result
CHANGING data = ls_pers
onresp ).
LOOP AT ls_personresp-data INTO ls_persondata.
lv_id = ls_persondata-person-id.
ls_oblnk-object_type = 'EMPLOYEE'.
ls_oblnk-object_key = ls_pernr-low.
ls_oblnk-ext_object_type = 'PERSON'.
ls_oblnk-ext_object_key = lv_id.
ls_oblnk-sys_comp = 'SAM_FSM'.
ls_oblnk-mobile_app = iv_mapp.
APPEND ls_oblnk TO et_oblnk.
CLEAR ls_oblnk.
ENDLOOP.
ENDIF.
ENDIF.
ENDLOOP.
ENDIF.
ENDMETHOD.
Use the importing parameter IO_ACI_SERVICE to execute a service call to Field Service Management for
retrieving the ID based on the code. See the following code example for more details.
Note
The following code is an example. You may need to make additional adjustments for your environment.
METHOD /merp/if_ca_fsm_crossref_badi~get_activity_id.
DATA:
lv_act_query TYPE string,
lv_id TYPE /smfnd/sync_object_key_dte,
lv_url TYPE string,
lv_char_code TYPE n LENGTH 3,
lt_actnr TYPE STANDARD TABLE OF /pacg/ecm_actnr,
lv_actnr TYPE /pacg/ecm_actnr,
lv_object_key TYPE /smfnd/sync_object_key_dte,
lt_error TYPE STANDARD TABLE OF ty_error,
ls_error LIKE LINE OF lt_error,
lt_actdata TYPE STANDARD TABLE OF ty_actdata,
ls_actdata LIKE LINE OF lt_actdata,
lv_status_code TYPE i,
lv_reason TYPE string,
lv_result TYPE string,
lv_raw_data TYPE xstring,
lv_aufnr_len TYPE i,
lo_descr TYPE REF TO cl_abap_elemdescr,
ls_aufnr_dfies TYPE dfies.
IF io_aci_service IS BOUND.
IF iv_aufnr IS INITIAL OR iv_vornr IS INITIAL.
RETURN.
ENDIF.
lv_object_key = iv_aufnr.
lo_descr ?= cl_abap_elemdescr=>describe_by_data( iv_aufnr ).
ls_aufnr_dfies = lo_descr->get_ddic_field( ).
lv_aufnr_len = ls_aufnr_dfies-leng.
lv_object_key+lv_aufnr_len = iv_vornr.
lv_char_code = lv_status_code.
IF lv_char_code CP '4*'.
ls_error-error = lv_result.
APPEND ls_error TO lt_error.
ELSE.
/aci/
cl_util_json_handler=>deserialize( EXPORTING json = lv_result
CHANGING data = ls_actres
p ).
LOOP AT ls_actresp-data INTO ls_actdata.
lv_id = ls_actdata-activity-id.
es_oblnk-object_type = 'OPERATION'.
es_oblnk-object_key = lv_object_key.
es_oblnk-ext_object_type = 'ACTIVITY'.
es_oblnk-ext_object_key = lv_id.
es_oblnk-sys_comp = 'SAM_FSM'.
es_oblnk-mobile_app = iv_mapp.
ev_id = ls_actdata-activity-id.
EXIT.
ENDLOOP.
ENDIF.
ENDIF.
ENDIF.
ENDMETHOD.
This method is a prerequisite for implementing relevant status updates from SAP Service and Asset
Manager to the Field Service Management planning and scheduling board. The method must return the
Field Service Management internal activity ID (the id field of the Field Service Management Activity entry)
based on the order and operation number provided.
The following code is an example. You may need to make additional adjustments for your environment.
METHOD /merp/if_ca_fsm_crossref_badi~get_serv_assign_id.
DATA lref_fsm_integration TYPE REF TO /merp/cl_ca_fsm_integration.
TRY.
" Create FSM object
CREATE OBJECT lref_fsm_integration
EXPORTING
iv_mapp = iv_mapp.
CATCH /merp/cx_core_exception_gen INTO DATA(lref_badi_exception).
RETURN.
ENDTRY.
" Fetch Service Assignment from FSM if it exists
lref_fsm_integration->query_fsm_serviceassign(
EXPORTING
iv_aufnr = iv_aufnr
iv_vornr = iv_vornr
iv_activity_id = iv_activity_id
IMPORTING
ev_id = ev_id
ev_activity_id = ev_activity_id
es_oblnk = es_oblnk
).
ENDMETHOD.
This method is a prerequisite for implementing relevant status updates from SAP Service and Asset
Manager to the Field Service Management planning and scheduling board. The method must return the
Field Service Management internal activity ID (the id field of the Field Service Management Activity entry)
based on the order and operation number provided.
Note
The following code is an example. You may need to make additional adjustments for your environment.
METHOD /merp/if_ca_fsm_crossref_badi~get_serv_assign_status_id.
DATA lref_fsm_integration TYPE REF TO /merp/cl_ca_fsm_integration.
TRY.
" Create FSM object
CREATE OBJECT lref_fsm_integration
EXPORTING
iv_mapp = iv_mapp.
CATCH /merp/cx_core_exception_gen INTO DATA(lref_badi_exception).
RETURN.
ENDTRY.
lref_fsm_integration->query_fsm_serviceassignstatus(
EXPORTING
iv_aufnr = iv_aufnr
iv_vornr = iv_vornr
iv_activity_id = iv_activity_id
IMPORTING
ev_id = ev_id
es_oblnk = es_oblnk
).
This method must return a TRUE (X) value if the supplied order ID or order type is valid for replication to
Field Service Management. The status changes on the operation (activity in Field Service Management)
are replicated to the Field Service Management Scheduling and Dispatching board only if a TRUE value is
returned by the method.
If this method isn't implemented, by default no replication of status occurs from SAP Service and Asset
Manager to Field Service Management
Context
The following configuration is needed to establish a connectivity between SAP Service and Asset Manager and
Field Service Management. For information on announcing root certificate change, refer to Announcing Root
Certificate Change.
Procedure
Note
b. Install the ISRG Root X1 certificate against the SSL Client (Anonymous) in the Trust Manager.
3. Create RFC destinations in the back end:
a. Create a destination for establishing the oAuth connection between the back end and Field Service
Management with the following parameters:
Procedure
1. Log on to the Administration and Monitoring Portal in the backend using transaction /SYCLO/ADMIN.
Under the Administration tab, select Server Management.
2. Create a new server with the name SAM_FSM for the application
SAP_SERVICE_ASSET_MANAGER_<version>.
The following additional server parameters can be defined if needed but they are optional. Their default
values are also specified below. Changing these values may result in the need for customers to customize
their backend integration code.
BUSINESSPARTNER BusinessPartner.23
ADDRESS Address.21
PERSON Person.24
SERVICEASSIGN ServiceAssignment.28
SERVICECALL ServiceCall.26
ACTIVITY Activity.39
SERVICEASSIGNSTATUS ServiceAssignmentStatus.15
ITEM /api/data/v4/Item
PERSON /api/data/v4/Person
BUSINESSPARTNER /api/data/v4/BusinessPart-
ner
SERVICEASSIGN /api/data/v4/ServiceAs-
signment
QUERY /api/query/v1
SERVICEASSIGNSTATUS /api/data/v4/ServiceAs-
signmentStatus
SERVICECALL /api/data/v4/ServiceCall
SERVICEORDERCREATE /service-manage-
ment/api/v2/composite-
tree/service-calls?autoCrea-
teActivity=false
ACTIVITY /api/data/v4/Activity
Prerequisites
Ensure the FIELD_SERVICE_TECHNICIAN persona is added and activated in the Administration and Monitoring
Portal.
For detailed information about personas and how they work, see the Configuring Personas and Features
Overview [page 66] topic and subtopics.
Use the following procedure to enable the FSM_SCHED_INTEGRATION and CA_LOCATION_UPDATE features.
They are disabled by default.
Procedure
1. From the ConfigPanel home screen, navigate to Component Assignments Select Mobile Application
User Personas tab . You can then filter for only the FIELD_SERVICE_TECHNICIAN user persona, if desired.
2. Click the Change button.
3. Check the Active Flag for CA_LOCATION_UPDATE and FSM_SCHED_INTEGRATION.
The only assignment type supported for the Field Service Management solution is Assignment Type 2.
Therefore, status changes are only supported at the operation level.
The following table shows the default SAP Service and Asset Manager statuses supported for the Field Service
Technician persona as defined in the Mobile Status Settings Configuration on the ConfigPanel:
WO_OPERATION REJECTED
WO_OPERATION ONSITE
WO_OPERATION HOLD
If any additional SAP Service and Asset Manager statuses are used or a custom service workflow is used in
Field Service Management – the additional statuses can be configured in the Mobile Application Mobile
Status Settings Configuration . In this case, customization may be needed at the backend and/or MDK level
depending on how the statuses need to be used.
SAP Service and Asset Manager supports expense and mileage entries for the Field Service Technician
persona.
The configuration of separate Activity Types and Work Center combinations are required to be able to
enter expenses and mileage using SAP Service and Asset Manager. Expenses and mileage are entered as
IW41 confirmations in the back end. Both planned and unplanned mileage recordings are supported. Since
the Expense and Mileage entries are stored in the backend as confirmations, due to the limitation of the
corresponding field in the backend, a single decimal place is supported for the Expense and Mileage values.
Note
Since the IW41 confirmation only supports time-related units of measurement (for example hours and
minutes), dummy units of measurement are displayed on the screen to make it more user friendly.
However, the confirmation is posted to the back end with the Unit of Measure Minutes by default.
Note
Expense and Mileage entries are stored in the back end as confirmations. Due to limitations of the
corresponding field in the back end, a single decimal space is supported for expense and mileage values.
The parameters configured in the Configuring Mileage and Expense Parameters [page 269] procedure display
as the Activity Type and Work Center fields in the app after you enter the order and operation number. If the
Work Center parameter isn’t defined, then this parameter is inherited from the operation. You can select a
different Activity Type and Work Center, but it requires knowledge on the values that are selected to avoid
errors when the data is posted to the back end.
Prerequisites
Expense and mileage reporting is enabled on the mobile app when the following conditions are met:
Note
You can enable the expense reporting and mileage reporting features for the Maintenance Technician
persona.
Context
• EXPENSES group:
• ExpenseActivityType: Activity type created for expenses. The defined value is the default displayed in
the Expense Type field on the app.
• ExpenseWorkCenter: The work center associated with the activity type defined for expenses.
• MILEAGE group:
• MileageActivityType: Activity type created for mileage.
• MileageWorkCenter: The work center associated with the activity type defined for mileage.
• MileageUOM: The unit of measure (for example, miles or kilometers) displayed on the app.
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.
2. The ExpenseActivityType and ExpenseWorkCenter parameters are found in the EXPENSES group. You
can scroll down to find the parameter, or perform a search using the Search box. Highlight the desired
parameter and click the Change button.
3. Configure the expense parameters as desired.
Note
The UOM for expenses displayed on the SAP Service and Asset Manager screen is the currency field
inherited from the order header.
4. The MileageActivityType, MileageWorkCenter, and MileageUOM parameters are found in the MILEAGE
group. You can scroll down to find the parameter, or perform a search using the Search box.
When planned expenses and mileage are supported, certain assignment types are not impacted, while others
must be addressed.
Since the planned expenses and mileage would involve adding additional operations, additional administrative
steps or configuration may be needed to ensure that all operations, including expenses and mileage
operations, are downloaded to SAP Service and Asset Manager.
The following header assignment types are not impacted, because the entire order with all the operations is
downloaded to the SAP Service and Asset Manager:
• Operation Level Personnel Number: To ensure that the planned expense and mileage operations are
downloaded, ensure that each technician who works on the order is assigned to operations with expense
and mileage activity types.
• Sub-Operation Level Personnel Number: To ensure that the planned expense and mileage operations are
downloaded, ensure that each technician who works on the order is assigned to operations with expense
and mileage activity types.
• Capacity Requirements: Planned operations with the expense and mileage activity types must be
assigned to all technicians working on the order.
• Operation Level Work Center: If the customer has different work centers for mileage and expenses, a
user attribute must be created to support multiple work center assignments. This user attribute must
be assigned to the OPER_WORK_CENTER filter of the SAM2205_WORK_ORDER_GENERIC oMDO. Ensure
that the expense and mileage work centers are also assigned to the technician via the User Administration
section in the Administration and Monitoring Portal.
SAP Service and Asset Manager supports FSM smartforms that allow planning board administrators to
efficiently gather technician activity information in an organized way. Planning board administrators can assign
Prerequisites
To use and preconfigure the FSM smartforms within SAP Service and Asset Manager, refer to the SAP Service
and Asset Manager Integration with Field Service Management Scheduling [page 252] section.
MAIF has an oData Model that defines configurations and settings for sets of entities. Similarly, FSM has a
data model for various entities, which are called DTOs. The DTOs have different versions as new features are
developed for each DTO.
Context
Procedure
1. Log in to the Administration and Monitoring Portal in the backend (transaction code /SYCLO/ADMIN). On
the Administration tab, select Server Management.
2. In the search parameters, enter:
• Mobile Application = SAP Service and Asset Manager 2210
• Server Name = SAM_FSM
3. Select the appropriate entry in the search results and navigate to the Additional Properties tab in the
Middleware Server Detail section.
4. Add the following properties in the Property List:
HEADERPARAM ATTACHMENT_DTO_VERSION 14
HEADERPARAM INSTANCE_DTO_VERSION 19
HEADERPARAM ITEMPLATE_DTO_VERSION 19
The DTO versions can be changed to a newer version if necessary. For more information on DTO versions,
refer to the [Link]
[Link] documentation.
Context
Procedure
Linear assets are technical systems with a linear infrastructure whose condition and properties can vary from
section to section (dynamic segmentation). You can see linear asset data associated with various objects such
as work orders, operations, technical objects, and notifications.
In addition to the basic SAP Service and Asset Manager configuration, there are a few considerations when
configuring SAP Service and Asset Manager with Linear Asset Management (LAM).
Note
Before configuring LAM on your system, see 2900476 so that the LAM exchange works properly.
Linear Asset Management (LAM) is especially designed to meet the requirements of linear asset maintenance.
A linear asset is a special type of asset that has an associated length dimension. This dimension is represented
through starting and ending points or by specifying the asset length. For the mobile device, the linear asset
management functionality enables the field technician to work on orders and notifications that have linear
equipment and functional locations. Field personnel can create work orders, notifications, time confirmations,
and material confirmations for the linear assets.
From the mobile device, you can view linear data for the following:
• Work orders
• Operations
• Notifications
• Items
• Equipment
• Functional locations
• Confirmations
• Measuring points
• Measurement documents
Note
As of the SAP Service and Asset Manager 2205 release, enable and disable parameters are no longer
available through the Parameters tab. You enable or disable all features through the Features tab. See the
Configuring Features [page 73] procedure for details.
• LAM_OBJECT_DATA
• LAM_OFFSET_TYPE
• LINEAR_REFERENCE_PATTERN
For general information on configuring OMDOS, see the OData Channel Integration Settings Procedures topics
found in the Mobile Add-On Configuration Configuration Panel Common Procedures chapter of this guide.
The functionality of adding or editing linear data for characteristics defines segments of a linear asset where
a specific attribute, or characteristic value, is valid. A segment is defined by start point, end point, length, and
unit of measurement (linear data).
Note
• Linear data for characteristics works only for characteristics that are marked as relevant for linear
asset management.
• To use linear data for characteristics, create a special Organizational Area and assign it to the relevant
classes and characteristics.
• It’s possible to assign several characteristic values in different segments of a linear asset. Therefore,
set the value assignment to multiple values when the characteristics are created.
The Meter Management component is delivered out of the box with predefined settings, which you can change
according to your back-end system setup. The following settings, however, have to be set:
• Binding Industry Solutions & Utilities (ISU) process type to work order type
• Setting the optimal meter reading history
• Binding meter reading reason relevant for technical installation
• Binding meter reading notes based on the ISU process type
Binding the ISU process type to the work order type provides the SAP Service and Asset Manager application
the correct representation of what process type is being conducted with the different work order types. This
binding is located in the SAM2305_ORDER_ISULINK OMDO, under the Read filter. You can update these filters
according to your business process.
All assignment types are supported for the Meter Management component.
The following filters represent binding criteria for different process types. By default, the ISU process types are
bound to order types as follows:
Mandatory
Mandatory
Mandatory
To change the default binding for a particular process, complete the steps below:
1. On the ConfigPanel home page, choose OData Mobile Data Object Configuration.
Make sure that 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 desired OMDO object, such as SAM2305_ORDER_ISULINK,
and then click the Data Filter tab.
3. Expand the Defined Filters list under the READ operation with the standard filter. Select the filter that you
want to update from the list of available filters as listed in the table in this topic. Choose the Change button
from the menu.
4. Set the order type for the desired process type you have selected.
5. Save your changes.
The back end ISU system configuration specifies which meter reading notes are relevant for the
major ISU process types. This configuration has to be replicated in the OData Mobile Data Object
SAM2305_METER_READING_NOTE under the READ operation with the standard filters, so that the SAP
Service and Asset Manager application reflects the proper meter reading notes for a specific process type. The
default configuration lists the meter reading notes relevant for the ISU process. However, you can change it if
you have different requirements in your back end configuration.
05
METERREAD_NOTE _IN- Standard Filter, Mandatory 01 Used for the meter read-
STALL ing notes for the installation
04
process
METERREAD_NOTE _RE- Standard Filter, Mandatory 04 Used for the meter reading
MOVE notes for the remove process
05
To change the default binding for a particular process, complete the following steps:
1. On the ConfigPanel home page, choose OData Mobile Data Object Configuration.
The default setting for meter reading history is to include all meter readings from the past 30 days till the
current day. If you have a different requirement, you can change it from the OData Mobile Data Object
SAM2305_METER_READING under the READ operation with the standard filter METERREAD_SCHEDDATE
as shown in the following example.
The back end ISU system configuration specifies explicitly which meter reading reasons are relevant for
technical installation. These are the only reasons displayed on the SAP Service and Asset Manager application
when completing a meter reading during the technical installation process. Set this binding in the OData
The default configuration contains meter reading reasons 08 and 09 as required for technical installation. If
you have different requirements for your back end configuration, you can change these defaults.
The Quality Management application component supports tasks associated with quality planning, quality
inspection, and quality control. In addition, it controls the creation of quality certificates and manages
problems with the help of quality notifications.
Quality Management (QM) notifications are integrated with SAP Service and Asset Manager as follows:
Note
Before configuring QM, you must install the QM component. See the Quality Management chapter in the
SAP Asset Manager Component Installation Guide for the installation procedure.
Quality Management is disabled on an out-of-the-box new SAP Service and Asset Manager installation. Use the
following topics and procedures found in this chapter to enable Quality Management.
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 following parameter groups and associated parameters to configure Quality Management in SAP
Service and Asset Manager:
• QMFORMULA: Inspection lots can contain points or characteristics. You can use the following formula
parameters to determine the characteristic value:
• C0: Arithmetic mean of measured values for characteristic. Standard parameter.
• C5: Upper limit of tolerance range
• C6: Lower limit of tolerance range
• C7: Target value of characteristic
• CATALOGTYPE: Sets a usage decision on inspection lots on the client. Standard is 3
• DOCUMENT: Standard is QMQMEL
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.
2. Type your desired parameter group into the Search box, or scroll to find your parameter. Highlight the
parameter you want to configure and click the Change button. The following example uses the parameter
group QMFORMULA.
Results
Complete all other topics and procedures in the Quality Management Configuration [page 280] to fully
configure and enable the Quality Management feature.
For general information and a procedure on changing OMDO data filters, see the following topics:
To fully enable Quality Management, ensure that the following data filters and data filter rules are configured
properly and active:
SAM2305_CATALOG_CODES
Select SAM2305_CATALOG_CODES from the oData Mobile Data Object List and navigate to Operation -
READ Standard Filter CATALOG_TYPE . Ensure the following rules in the <Rule Value> field are set to
Active:
• 8 - Activities (QM)
• 9 - Defect Types
• D - Coding
SAM2305_DOCUMENT
When you enable QM on the SAM2305_DOCUMENT data filter, you enable the ability to attach documents
to an inspection. When mobile client users take a reading on the SAP Service and Asset Manager application,
they can attach documents that relate to the inspection on work orders, equipment, functional locations, or
notifications.
Select SAM2305_DOCUMENT from the oData Mobile Data Object List and navigate to the following locations:
• QMQEL: QM notification
• QMTBLOC: Inspection method
Navigate to Operation - READ Standard Filter DOC_LINK_OBJ and ensure the following are set to
Active:
SAM2305_INSPECTION_LOT
Set the dependency to get inspection lots based on work orders related to the inspection assigned to the
mobile client user as follows:
Select SAM2305_INSPECTION_LOT from the oData Mobile Data Object List and navigate to Operation -
READ Data Distribution OBJECT_DISTRIBUTION_MODE . Ensure that <Range Value> 2 - Dependency
Queue is set to Active.
Navigate to the Dependent Object tab. Ensure that <Source Tech Entity Type> INSPECTIONLOT is
connected to <Dependent oMDO ID> SAM2305_NOTIFICATION_GENERIC and is set to Active. When a
mobile client user fetches the inspection lots, the related defects, created as QM notifications, are fetched as
well.
Ensure that <Source Tech Entity Type> INSPECTIONCHAR is connected to <Dependent oMDO ID>
SAM2305_INSPECTION_HISTORY and is set to Active. The fetched inspection history is based on the
inspection characteristics available.
SAM2305_NOTIFICATION_GENERIC
Select SAM2305_NOTIFICATION_GENERIC from the oData Mobile Data Object List and navigate to
Operation - READ Data Distribution NOTIF_ASSIGNMENT_TYPE . Ensure that <Range Value> D is
active.
Navigate to Operation - READ Data Distribution NOTIF_TYPE . Ensure that <Input Parameter> QM is
active.
SAM2305_NOTIF_PARTNER_DET_PROC
Select SAM2305_NOTIF_PARTNER_DET_PROC from the oData Mobile Data Object List and navigate to
Operation - READ Standard Filter NOTIF_TYPE . Ensure that <Input Parameter> QM is active.
Select SAM2305_NOTIF_TYPE from the oData Mobile Data Object List and navigate to Operation - READ
Standard Filter . Ensure that Quality Management is enabled in the following locations:
SAM2305_PRIORITY
Select SAM2305_PRIORITY from the oData Mobile Data Object List and navigate to Operation - READ
Standard Filter PRIORITY_TYPE . Ensure that <Rule Value> QM is active.
SAM2305_WORK_ORDER_GENERIC
Enable the dependency between a work order and a related inspection lot on the mobile device:
Navigate to the Dependent Object tab. Find the WOHEADER objects in the <Source Tech. Entity Type>
column. Scroll to find the SAM2305_INSPECTION_LOT object. Ensure it is marked as Active.
SAP Web IDE is a browser-based IDE consisting of integrated parts that interact with each other and with an
SAP system.
SAP Web IDE Full-Stack streamlines the end-to-end application lifecycle – easily develop, test, build, deploy,
and extend role-based, consumer-grade apps for business users. Create applications rapidly and deliver an
outstanding user experience. Developers can extend or build SAP Fiori apps, create SaaS solutions, extend
SAP S/4HANA cloud services, develop hybrid mobile applications, and build IoT apps for SAP Leonardo, using
the UI development toolkit for HTML5 (SAPUI5) for desktop and mobile devices, SAP HANA toolset, and Java
programming language and technologies. Since SAP Web IDE Full-Stack runs on SAP Business Technology
Platform, it needs no installation and allows you to integrate with other services that run on the platform – such
as SAP Fiori Cloud apps, Git integration, mobile services, IoT services, and more.
Architecture
The following diagram provides high-level typical architecture for SAP Web IDE Full-Stack.
Component Description
SAP Business Technology Platform SAP Business Technology Platform enables customers and
partners to rapidly build, deploy, and manage cloud-based
enterprise applications that complement and extend your
SAP or non-SAP solutions, either on-premise or on-demand.
SAP Business Technology Platform cockpit Central point for managing all activities associated with your
SAP Business Technology Platform account and for access-
ing key information about your applications.
SAP Web IDE application Integrated development environment used to create or ex-
tend SAP UI5 or SAP Fiori applications.
SAP Business Technology Platform connector Allows SAP Web IDE and SAP Business Technology Platform
to connect to an on-premise system securely and with mini-
mal configuration effort.
SAP Gateway Provides a simple way to connect SAP Web IDE to an exter-
nal SAP system with access to OData functionality.
Note
When working in SAP Web IDE, the following operations may be processed by our partner Infrastructure-
as-a-Service (IaaS) providers:
• Code completion
• Code validation
These operations may involve transfer and process of data in different regions.
Who is it for?
SAP Web IDE is a flexible tool for developers who want to dive right into the code editor without having to spend
time configuring and administering the development environment.
The tool is aimed at developers who need a modern and secure environment to create new or extend existing
SAP Fiori, SAPUI5, or hybrid applications. Developers are provided with a comprehensive set of tools, including
strong code editors with templates, wizards, beautifier capabilities, code completion, code snippets, code
validation, code checking, WYSIWYG, and many more features.
Note
The Mobile Development Kit for SAP Business Technology Platform Mobile Services is a metadata-based
application development platform.
The Mobile Development Kit (MDK) lets you customize, deploy, and manage your customized Windows apps
in the cloud. The Mobile Development Kit editor lets you edit various aspects of your application using the
Mobile Development Kit editor. It also provides native client support and consumes mobile services such as
onboarding, offline OData, life-cycle management, and supportability through the SAP Business Technology
Platform Mobile Services using the Mobile Development Kit client.
The Mobile Development Kit allows business process experts to customize the app in a cloud-based editor
using the SAP Web IDE, and developers to edit code directly in the metadata files.
The end-to-end use case for Mobile Development Kit includes tasks involving the following roles:
• Administrator
• Business process expert
• Developer
• User
One of the main purposes of the Mobile Development Kit is to easily customize and redeploy metadata for your
SAP Service and Asset Manager application.
Restriction
Develop any customization on the app as a separate component in a Mobile Development Kit project.
Developing customizations as a component makes it easier to maintain customizations during upgrades,
as it isolates custom code. Isolating your custom code eliminates the chance of overwriting when you
implement a new release.
A typical metadata customization procedure is as follows. This example assumes that metadata definitions
already exist in the Mobile Development Kit and that you’re customizing them, or changing them:
1. Locate the object you want to modify. You can modify pages, actions, or rules. See the following topics
and subtopics for more information on how to create and modify the following metadata objects using the
Mobile Development Kit:
• Create Pages
• Create Actions
• Create Rules
2. Deploy the metadata. See Deploying App Metadata from Editor to Mobile Services for more information.
Use the following rules in the metadata to customize the contextual menu options:
• Rules/[Link]
• Rules/[Link]
• Rules/[Link]
Reminders Delete
Errors Delete
For detailed information on working with metadata contained in the Mobile Development Kit, see the SAP
Mobile Development Kit API References portal, specifically, the ObjectCell control
Procedure
Allow Upload of Pending Changes from Previous User ensures that any pending offline changes from the
previous user are securely uploaded to the service back end. This is important when the previous user
hasn't uploaded the offline changes, and the app is switched to a new user.
Cloud Foundry
In Cloud Foundry, Allow Upload of Pending Changes from Previous User is available in Mobile Settings
Exchange feature under Shared Devices section.
Note
In Cloud Foundry, when you enable Allow Upload of Pending Changes from Previous User, you must
also enable Passcode Policy. Passcode Policy checkbox is under Assigned Features Mobile Settings
Exchange .
Neo
In Neo, Allow Upload of Pending Changes from Previous User is available in Client Policies feature under
Shared Devices section.
In Neo, when you enable MultiUserEnabled, you must also enable Allow Upload of Pending Changes from
Previous User and Passcode Policy to be able to onboard. Passcode Policy checkbox is under Assigned
Features Client Policies .
In multi-user use case, the backend needs to know when a user switch has occurred when client performs a
sync.
Context
On client, tracking the current user is necessary. If the user has changed, in the subsequent sync the user
switch flag must be set to true, if not, set to false.
Procedure
Procedure
Logout action
1. Set SkipReset flag to True in [Link].
The invocation of logout action redirects the user to the Sign-in screen. By re-entering the passcode, the
user can relogin and start using the app. In a multi-user scenario, it's recommended that each user log out
before they hand over the device to a different user. The default value of this flag is False, which means
that when the app is reset, the stored credentials are deleted. It's recommended to set this flag to True in
a multi-user scenario. The [Link] file is called when the user switches user and the Multi-User
mode is enabled. All the pending Offline OData transactions from previous user are synced.
2. Call the isAppInMultiUserMode function to determine if the app is in single or multi-user mode.
Push Notifications
3. Unregister for push notifications during the logout action, and reregister during the OnLoaded event for the
next user.
When a user logs out, the user is unregistered for the push notifications. When a user signs in, the
OnLoaded event automatically switches the push registration to the logged-in user.
Context
Multiple users can log in to the same device via using a QR code.
Procedure
1. Create a QR code with CPms, and make sure that the Allow Upload of Pending Changes from Previous User
flag is checked.
You can navigate to Allow Upload of Pending Changes from Previous User from Mobile Settings Exchange
Shared Devices .
After logging out, you can add a new user or switch between users.
Next Steps
Verify that the switch user can be done successfully with and without pending transactions.
Deep linking refers to URIs that are opened outside an application, through a link from another application.
When a user opens a deep link, the user is navigated to a specific resource within the application.
Deep linking configuration is performed through the metadata. See Customizing Metadata Using the Mobile
Development Kit [page 287] for information on working with metadata.
Deep linking supports the Create, Update, and View actions. See the following sections for objects supported
and examples of deep linking schemas for the objects.
Note
If your mobile user is not allowed to create, update, or view an object on the client, that object is also
disabled from the deep link. If your mobile user is using a persona that does not work with the object (for
example, an inventory clerk persona is not configured to use work orders), the object is disabled from the
deep link.
Create Action
Priority
BusinessArea
MainWorkCenter
MainWorkCenterPlant
HeaderFunctionLocation
HeaderEquipment
MainWorkCenter
HeaderEquipment
Priority
TextTypeDesc
ItemCategory
Plant
QuantityUnE
StorageLocation
MaterialNum
UnitOfEntry
WithdrawnQuantity
UnitOfEntry
Update Action
BusinessArea
MainWorkCenter
MainWorkCenterPlant
HeaderFunctionLocation
HeaderEquipment
OperationEquipment
180'
OperationEquipment
010',SubOperationNo='0011'?
OperationFunctionLocation=1111-2
22-
AA-33&OperationEquipment=1006864
5&OperationShortText=data
Priority
AccountingIndicator
ActivityType
StorageLocation
MaterialNum
UnitOfEntry
View Action
Following is a list of all objects supported for the create action (entitysetName, list of supported parameters).
Underneath each object is a deep link example:
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 Service and Asset 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 SAM2305_EQUIPMENT,
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 Service and Asset Manager application determines the assignment of work orders and
notifications using the personnel number assignment at header level. However, implementation environments
in different industries or business types may use a different assignment model from the default to determine
the proper technician assignment for work orders and notifications. The SAP Service and Asset Manager
application supports several assignment models; you only need to change the assignment type configuration
for the specific model.
See Business Object Distribution by Assignment Model [page 134] for more details about assignment model
distribution, and how to change assignment type for both work order and notification.
The filters listed in the following table are common to all SAP Service and Asset Manager distribution rules. See
the specific rules for details on filter requirements for those rules.
WO_ASSIGNMENT_TYPE Data Distribution, Mandatory See specific rule Defines which distribution model is
for value used
ORDER_CATG Data Distribution, Optional See specific rule Restricts work order distribution
for value based on work order category. For
maintenance orders, it should be
value 30.
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.
User Parameter IDs are used to filter data that mobile users download when they perform a sync. By setting
the Parameter IDs for users, you can define which assignment types technicians will receive and which
activities they have to complete on their mobile devices. To update these IDs in your user profile, perform
the following steps:
Note
• To display other users' Parameter IDs, use the transaction code SU01D on the SAP GUI.
• You need authorization to edit the list of User Parameter IDs for other users.
The following table lists all User Parameter ID values available in SAP Service and Asset Manager:
WRK Plant
Note
For more information about which assignment types require User Parameter IDs, see:
The standard SAP Service and Asset Manager application work order distribution is controlled by the OMDO
(OData mobile data object) SAM2305_WORK_ORDER_GENERIC READ operation. It supports several data
distribution models for the work order.
You can choose the appropriate distribution model based on your specific business processes and
requirements.
Requirements
The following are requirements before configuring the distribution model for Distribution by Work Order
Header Person Responsible:
Requirements
The following are requirements before configuring the distribution model for Distribution by Work Order
Header Person Responsible:
• Mobile user (i.e., the technician) must have an employee number (personnel number) assigned in SAP
• Employee number is assigned to the work order operation as the person responsible
• Work order is released
• Work order is not marked for deletion
Requirements
The following are requirements before configuring the distribution model for Distribution by Work Order
Suboperation Person Responsible:
• Mobile user (i.e., the technician) must have an employee number (personnel number) assigned in SAP
• Employee number is assigned to the work order suboperation as the person responsible
• Work order is released
• Work order is not marked for deletion
Requirements
The following are requirements before configuring the distribution model for Distribution by Capacity
Requirement Person Responsible:
• Mobile user (i.e., the technician) must have an employee number (personnel number) assigned in SAP
• Employee number is assigned to the work order capacity requirement split records as the person
responsible
• Work order is released
• Work order is not marked for deletion
Requirements
The following are requirements before configuring the distribution model for Distribution by Work Order
Header Planner Group:
• Mobile user (i.e., the technician) has been assigned to the planner group based on the business
• Employee number is not required
• Planner group associated with the mobile user is assigned to the work order header
• Work order is released
• Work order is not marked for deletion
Requirements
The following are requirements before configuring the distribution model for Distribution by Work Order
Operation Work Center:
• Mobile user (i.e., the technician) has been associated with a work center in business
• Employee number is not required
• Work center associated with the mobile user is assigned to work order operation
• Work order has been released
• Work order has not been marked for deletion
Requirements
The following are requirements before configuring the distribution model for Distribution by Work Order
Header Business Partner:
Requirements
The following are requirements before configuring the distribution model for Distribution by Work Order
Header Work Center:
• Mobile user (i.e., technician) has been associated with a work center based on the business
• Employee number is not required
• Work center associated with the mobile user is assigned to the work order header
• Work order is released
• Work order is not marked for deletion
Requirements
The following are requirements before configuring the distribution model for Distribution through MRS
Scheduling Engine:
• MRS has been implemented in the SAP system, and is responsible to schedule and update work order
capacity records with the assigned technician
• Employee number is required for the mobile user
• Work order is released
• Work order is not marked for deletion
Requirements
The following are requirements before configuring the distribution model for Distribution by Free Search:
• Free search criteria for the work order. Used for an OnDemand work order look-up scenario.
• Employee number is not required
• Work order is released
• Work order is not marked for deletion
The OMDO (OData mobile data object) SAM2305_NOTIF_ASSIGNMENT_TYPE READ operation controls
the standard SAP Service and Asset Manager application notification distribution. It supports several data
distribution models for the notification.
You can choose the appropriate distribution model based on your specific business processes and
requirements.
Notification requests are assigned to the technician directly or assigned through the work center, planner
group, or related business partner of the technician. The SAP Service and Asset Manager application supports
these different assignment types while downloading notifications associated with the technician.
• 1 - Header Level Person Responsible: Assign this notification to the HR personnel number of the
technician through the notification header Partner section.
• 2 - Notification Task Level Personnel Number: Assign this notification to the HR personnel number of the
technician through individual Task Personnel Number field.
• 3 - Header Level Planner Group: Assign this notification to the planner group associated with the
technician through the header level Planner Group field.
• 4 - Header Level Business Partner: Assign this notification to the business partner associated with
the technician through header level Partner Function Maintenance. The business partner can be anyone
related to the notification partner function and associated with the technician, such as user responsible,
sold-to-party, or other party. If there is no MAM configuration set up for the user, the default configuration
uses VU-User Responsible as the default partner function and the technician SAP User ID as the partner
number.
• 5 - Header Level Work Center: Assign this notification to the work center associated with the technician
through the header level Work Center field.
• D - Dependency Queue: Enables the dependency queue from the work order. When active, all notifications
associated with a work order are downloaded, as well as qualifying data based on additional distribution
rules that are set.
Customers can choose the appropriate distribution model based on their specific business processes and
requirements.
Requirements
The following are requirements before configuring the distribution model for Distribution by Notification header
Person Responsible:
Requirements
The following are requirements before configuring the distribution model for Distribution by Notification task
level Personal Responsible:
Requirements
The following are requirements before configuring the distribution model for Distribution by Notification header
level Planner Group:
Requirements
The following are requirements before configuring the distribution model for Distribution by Notification header
level Business Partner:
Requirements
The following are requirements before configuring the distribution model for Distribution by Notification header
level Work Center:
Requirements
The following are requirements before configuring the distribution model for Distribution by Free Search:
• Free search for notification used for an on-demand notification look-up scenario
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 Service and Asset 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 an 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.
Bias-Free Language
SAP supports a culture of diversity and inclusion. Whenever possible, we use unbiased language in our documentation to refer to people of all cultures, ethnicities,
genders, and abilities.
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.