Professional Documents
Culture Documents
2018-05-28
Run Simple
Content
3.4 Version Management of Business Partner Master Data: Implementation with RFC. . . . . . . . . . . . . . 24
4.1 Adding Customer Fields to the RFC APIs and Internal Structures. . . . . . . . . . . . . . . . . . . . . . . . . . .28
4.2 Adding Customer Fields to the Web Service for Business Transaction Screening. . . . . . . . . . . . . . . . 32
6.1 Creating Additional Apps and Tiles for the SAP Fiori Launchpad. . . . . . . . . . . . . . . . . . . . . . . . . . . 38
SAP Business Partner Screening is a generic application. It makes it possible for you to use the speed and
power of SAP HANA for screening business partners against lists of persons and organizations published by
governments and institutions across the world.
Note
This document is for consultants and developers who plan to extend SAP Business Partner Screening.
This document explains how to extend this solution in the following ways:
More Information
SAP Business Partner Screening offers an RFC and web service programming interface (API) for screening
business partners who appear in business transactions against screening lists. This API makes it possible for
you to use the real-time address screening features of the software for anti-corruption compliance and risk
avoidance in business transactions from SAP Systems and non-SAP systems.
The API is held in package BPCM_RFC, which you can access with the ABAP Workbench, transaction SE80 or
with the Eclipse-based ABAP Development Tools. You will find online documentation on the function modules
and parameters in your system.
● Access to address screening of business partners in business transactions in real time. The speed of
SAP HANA makes it possible to integrate business transaction screening directly into your business
processes. It is not necessary to screen transactions asynchronously.
● Delta address screening. Business transaction data is retained at the SAP Business Partner Screening
system. As screening lists are updated, business partners in transactions can be checked against the
changed information in the lists. (Alerts are not propagated automatically to your business system in this
case).
● Simple integration in your business systems. You can implement address screening (which comes with
automatic inclusion of business partners in delta address screening) for business transactions with only
one or two RFC function module calls, depending on the options that you use.
● Compatibility: Access to address screening via an RFC interface or web service from SAP business
systems or via web services from non-SAP systems.
Before you can use the web service or RFC API for business transaction screening, you must ensure that
configuration and customizing tasks have been done in SAP Business Partner Screening. The following tasks
must be done:
● The address screening feature must be enabled. Business transaction screening uses address screening.
You can also find information about address screening in the application help at http://help.sap.com/
bps_s4 .
● Customizing tasks must also be done to enable business partner screening.
In particular, you can add investigation and detection object types if the standard Sales Order and Purchase
Order types are not suitable. Also, you may wish to add customer fields to your investigation and detection
object types in order to enrich the information in alerts or refine the selection of detection strategies for
screening. Additionally, you must define a default investigation reason for alerts.
If your business system is an SAP system, then you can set up an RFC destination to the SAP Business
Partner Screening system for calling the RFC API. Otherwise, you can use the
BusinessTransactionCheck_Request_Sync_In enterprise web service to call business transaction
screening.
You will also find information about specific customizing requirements in the online documentation of the
RFC function modules in package BCPM_RFC in the SAP Business Partner Screening system.
● Assign authorizations to RFC or web users in SAP Business Partner Screening. Such users must have the
SAP_BPCM_SYS_COM role.
Business transaction screening in SAP Business Partner Screening uses a simplified model of a business
transaction. This requires you to map from the data model of a business transaction in an ERP system to the
simplified BPS model.
This section briefly describes the data models and the mapping between them.
The following diagram shows the logical data model of business transactions in source business systems. It is a
generalized model for all types of business transactions – sales orders, purchase orders, and so on. The model
depicts only the aspects of a business transaction that are relevant for address screening.
A business transaction consists of a header and one or more items. One or more business partners can appear
in both the header and in the items of a transaction. The role of a partner in a transaction is documented by
assignment to a partner function in the transaction, such as the sold-to, bill-to, payer, and ship-to parties.
An address in the header is also valid for all items of the business transaction. The diagram therefore shows an
n..m relation between a header address and items.
However, if at the item level an address is assigned for a partner function, then this address is valid for a
particular item instead of the header address of same partner function.
Most addresses in business transactions are addresses of master data objects that are assigned to business
transactions. These addresses are stored as business partners, vendors, customers and so on. Such addresses
have a master data identification that can be supplied with a call to the business transaction screening
interface for inclusion in alerts for documentation purposes. However some addresses can also be added to a
business transaction manually by entering the names and postal data.
As the diagram below shows, business transaction screening reduces the transaction data model shown above
to the elements essential for address screening.
As the diagram shows, the data model is reduced to the business transaction header - the identification of the
business transaction - and the business partner addresses that it contains.
As the diagram also shows, the business transaction header corresponds to an investigation object type in
SAP Business Partner Screening. An investigation object type represents the entity to investigate, in this case,
a business transaction.
For each type of business transaction, you can define a separate investigation object type. SAP delivers, for
example, investigation object types for sales orders and for purchase orders, and you can define additional
investigation object types. You associate business transactions with investigation object types by way of a
business transaction type. You define the business transaction types in Customizing and specify the type as
part of the key of a business transaction.
The typing concept and separate investigation object types for each transaction type let you tailor detection to
the transaction type. You can add a different set of customer fields to the API for each type of business
transaction. Such fields can be added to alerts as enrichment fields. Or they can be used as selection fields for
choosing the detection strategy with which to screen the business partners of a transaction. You can also
define a separate navigation for each transaction type. For example, you can navigate to a sales transaction for
sales orders, a purchasing transaction for purchase orders.
The business partner addresses in a business transaction correspond to detection object types. In SAP BPS,
these are the entities to examine for problems during screening against watch lists.
In business transaction screening, there is a 1 to n relation between an investigation object type and a detection
object type. The detection object type represents both "person" and "organization" business partners.
The following diagram shows the screening data model in more detail. See the online documentation in the
system for the BPCM_BUSINESS_TRANSACTION_CHK function module and related objects for details.
Transaction header and items: In reducing the transaction data model to fit the ACS data model, the
transaction screening API loses the distinction between business partner addresses appearing in the
transaction header and those appearing in transaction items. You simply provide all addresses to the BPS
system for screening. If the association of an address to the header or items is important to you, then you must
manage that information in the calling system.
Customer-added fields: May be added only at the business-transaction level of the data model. It is not
possible to add extension include fields to business partner entries. Your fields may serve as enrichment fields,
which are added as details to alerts. Or your fields can be selection fields, which help select the detection
strategies to use.
Selection of detection strategies: In addition to selection fields that you add, SAP Business Partner Screening
uses the business system, the risk level, the country derived from the organizational unit, and the country from
a business partner address to select detection strategies to run. Compliance and risk management
requirements vary by country; these standard selection parameters let you match the selected detection
strategies to the requirements that you have to meet. You can, for example, screen for risky countries more
intensively than low-risk countries.
Organizational unit and country of reference: You can specify only a single organizational unit for the
business transaction and the business partners it contains. It is the organizational unit that is responsible for
the business transaction.
Optionally, you can omit organizational units. In this case, you must define a default mapping entry for the
current business system in Map Organizational Unit in Customizing. This default entry then applies to all
business transactions from the business system.
Risk level: An optional value, defined in BPS Customizing, that indicates the severity of the compliance risk
posed by a business transaction. A sales order for military hardware has much greater importance and risk,
and needs to be more carefully screened, than a sales order for office supplies. More careful screening
translates in practice to more potential hits, so that no possible match is missed.
The risk level is also used as a selection parameter for choosing detection strategies.
Partner functions: If a business partner appears in a transaction more than once and with different partner
functions, then you supply the partner functions in a table associated with the business partner in the
screening API. You must supply at least one partner function for a business partner.
In Customizing, these external partner functions are mapped to internal partner functions. In the event of a
watch list hit and an alert, then the descriptive text from each relevant internal partner function is added to the
alert.
Partner ID and master data identification: You can supply identification information for a business partner, as
well as the ID of the partner in master data management. However, this information is for documentary
purposes.
In business transaction screening, each transaction and address are treated as "new". The API does not read
data from master data management, nor does it access a business transaction that has already been
submitted for screening and persisted. If a transaction is presented a second time, the new data simply
overwrites the old transaction data and addresses in the BPS storage. Always resubmit a complete transaction,
not just the deltas in the transaction.
This design allows you to respond flexibly with your detection strategies to the attributes of a business
transaction. Business partners in a more important business transaction can be subjected to more intensive
screening, for example, even if the partners have been seen and cleared before. The model does not allow for
assumptions that a certain business partner is already cleared, simply because the partner has already been
screened in the context of another transaction.
Access group: Lets you specify authorizations for accessing alerts. If an alert belongs to an access group (the
name of which you specified in your screening request), then only investigators who have an authorization for
the group can access the alert.
The diagram below shows the processing flow in business transaction processing. The business transaction
screening API offers all of the functionality shown in the "BPCM" frame. You must implement the call from the
"Source System" frame to request business transaction screening. And you must implement the reaction to
the results of screening in the "Source System".
You can transmit a screening request to SAP Business Partner Screening via RFC (function module
BPCM_BUSINESS_TRANSACTION_CHK Enhanced Business Transaction Address Check in function group
BPCM_ADDRESS_CHECK) or enterprise web service provider
(BusinessTransactionCheck_Request_Sync_In Check Business Transaction). You can transmit single or
multiple transactions with a request.
The business partners who appear in a transaction are subjected to address screening in SAP Business Partner
Screening. The system selects detection strategies for screening according to selection parameters. These
include the detection object type, the risk level, the country in an address, and the country of the organizational
unit. Any selection parameters that you add are also used in selecting strategies.
If there are hits in watch lists, then an alert is created and each hit is recorded as an alert item. The information
in an alert item includes the address that was screened, the matches from a watch list, the partner function,
and other information, including any enrichment fields that you add to the investigation object type.
In addition to address screening in real time, the system persists a business transaction with all of its business
partners. This persisted transaction is subjected to delta address screening, as changes to watch lists become
available. If you re-submit a business transaction, then it overwrites the persisted business transaction. There
is no change management or versioning of persisted transactions, and transactions should always be re-
submitted in full, not just as new or changed information. Alerts arising from delta screening are not
The results of screening are returned to your calling system synchronously. If you have cleared the
EV_INVESTIGATION_IN_BPCM parameter in function module BPCM_BUSINESS_TRANSACTION_CHK, then you
can communicate the decision on each alert with function module BPCM_ALERT_DECISION_CHANGE to the
SAP BPS system. Otherwise, investigation of an alert and the setting of the decision must be done in the BPS
system.
In the source system, you can take any required action as a result of screening alerts. You can, for example,
block the transaction until an investigation has been completed and an decision on alerts has been made.
This section briefly shows how to implement the RFC and web service interfaces for business transaction
screening in SAP Business Partner Screening (BPS).
RFC Implementation
To implement business transaction checking with the RFC interface, you need only implement function module
BPCM_BUSINESS_TRANSACTION_CHK (Enhanced Business Transaction Address Check) in your business
transaction process.
Add this function module to the process at the earliest when the ID of the business transaction has been
finalized. (If you need screening earlier in the process, then submit the business transaction (with a temporary
ID) in simulation mode. You receive screening results, but no alerts are created, nor is the business transaction
saved in the SAP BPS system.)
1. Map your business transaction data to the BPCM_T_OD_BT table structure used in parameter
IT_BUSINESS_TRANSACTIONS in function module BPCM_BUSINESS_TRANSACTION_CHK.
2. Call the function module at SAP BPS from your business system. If you are integrating an SAP business
process, you can use RFC. In this case, you must define an RFC destination in your system that points to
the SAP BPS system. Users who call the function module must have role SAP_BPCM_SYS_COM in the SAP
BPS system.
Since SAP BPS screens in real time, you can call the ABAP function module synchronously.
If you are calling the function from a non-SAP system or a non-ABAP system, then you can call the
enterprise web service (see below).
3. You can now present the results to your business users at the calling system. Users can decide whether a
hit – the discovery of a business partner in a watch list – is valid or should be ignored.
4. When the user has finished with step 3, you can set alert decisions in SAP BPS with the RFC function
module BPCM_ALERT_DECISION_CHANGE, if you have cleared parameter IV_INVESTIGATION_IN_BPCM.
For more information, see Sample Code and Usage Notes: BPCM_ALERT_DECISION_CHANGE Function
Module in Implementing the Interface for Business Partner Master Data Screening [page 15].
Here is sample code showing a call to BPCM_BUSINESS_TRANSACTION_CHK. Notes follow the example.
By default, alerts are created in SAP Business Partner Screening if a business partner is found in a watch list.
By setting the simulation indicator to 'X', you can suppress the creation of alerts. The function module still
returns hits to you if alerts are suppressed. Simulation is recommended only for test and development
operation. An exception: You can use simulated mode to test screen a transaction before it has received its final
ID number.
By default, alerts can be closed by users in SAP Business Partner Screening (IV_INVESTIGATION_IN_BPCM
= 'X'). Clearing this parameter prevents manual change of alert status in SAP Business Partner Screening. In
this case, you must report the results of the user decision on hits to the SAP Business Partner Screening
system in order to close any alerts that have been created (BPCM_ALERT_DECISION_CHANGE).
Fill this table parameter with the data of the business transactions. There are separate substructures for
business partners that are persons and for those that are organizations. For information about the data models
and mapping, see Business Transaction Screening: Data Model [page 6].
ACCESS_GROUP Authorizations
Optionally, you can use the ACCESS_GROUP parameter to restrict access to any alerts created by a
BPCM_PARTNER_CHECK call. A user at SAP Business Partner Screening must be authorized for the
ACCESS_GROUP value that you specify to access an alert.
Results
The ET_BUSINESS_TRANS_CHECK_RESULT export table returns any "hits", entries from watch lists that
matched to a screened person or organization. The tables contain entries only for addresses of business
partners for whom there were hits. The ALERT_INDICATOR field is also set if alerts were generated. An empty
table means that the screened persons or organizations in a business transaction were not found in the watch
lists that were applied.
Messages
Point to point communication is enabled, so that no Process Integration (PI) system is needed as a hub.
Input and output structures of the service are similar to those of the RFC API. Execution of address screening
of business partners is identical to that of the RFC API, with the exception of internal web service specialties,
such as the mapping of web parameters to internal data structures.
For:
● Inbound mapping of the enterprise service repository input to the data structures used by the API (as
described with respect to the RFC interface); and
● Outbound mapping from internal data structures to the ESR output
For more information, see Creating and Configuring Service Providers and Service Consumers.
SAP Business Partner Screening offers a programming interface (API) for performing business partner
screening. This API makes it possible for you to use real-time address screening features for anti-corruption
compliance and risk avoidance in SAP systems and non-SAP systems. You can implement the interface using
RFC function modules or an enterprise web services.
The RFC API is used in SAP’s own implementation of business partner screening for SAP Master Data
Governance release 8.0 and 9.0 ().
Alternatively, you can request screening of master data with the BusinessPartnerCheck_Request_In enterprise
web service.
This section provides help for both RFC and web service implementations of the API.
Business partner master data screening is used to check addresses of persons and organizations against
screening lists and has these features:
● Access to address screening of business partners in real time. The speed of SAP HANA makes it
possible to integrate business partner screening directly into your business processes. It is not necessary
to screen business partners asynchronously.
● Delta address screening. Business partner data is retained at the address screening system. As screening
lists are updated, business partner data can be checked against the changed information in the lists.
(Alerts are not propagated automatically to your business system in this case).
● Two integration models for the API.
○ At its simplest, you can implement only address screening (which comes with automatic inclusion of
business partners in delta address screening). You need implement only one or two RFC function
module calls, depending on the options that you use.
○ If you wish to, you can also implement a more sophisticated integration model that adds management
of business partner data in draft and active versions.
This version management lets you mirror master data change and approval processes in your business
system. Business partner data that is being created or edited is held as "draft" data in the address
screening system. When the business partner data is approved or the change is cancelled in your
business system, then you can propagate this action to this system. The data is saved as "active" data
at approval or is deleted if a data change is cancelled.
● Compatibility: Access to address screening via an RFC interface or web services from SAP Business
systems or via web services from non-SAP systems.
Usage Notes
● Business partner master data screening uses pre-configured sets of detection and investigation object
types, one set each for screening persons and organizations.
● Persons and organizations submitted online for screening are persisted (permanently saved) in the
system. This feature allows delta screening of business partners as screening lists change.
Note
Screening lists must be imported into the system before an address screening can take place.
Comprehensive screening lists can be obtained from external providers.
Address screening is performed after the input data of the persons and organizations has been stored. The
results of the screening are hits where the addresses of the input data match the entities of screening lists.
Entities on screening lists can also be persons and organizations.
A hit contains information about names and addresses of a screening lists entities, which matches a particular
name and address of the input data. The hit contains a search score and the information, which indicates why a
hit has been found, is highlighted. A hit also comprises references of the screening list entity to screening lists
as well as a higher level list classification.
If requested, the system will create an alert for the persons and organizations that have address screening hits.
In this case the alert IDs are returned to the calling system.
Before you can use the RFC API for business partner screening, you must ensure that configuration and
customizing tasks have been done in SAP Business Partner Screening. The following tasks must be done:
● The address screening feature of SAP Business Partner Screening must be enabled. Business partner
screening uses address screening. You can find information about enabling address screening in the
Installation Guide of SAP Assurance and Compliance Software for SAP S/4HANA at http://help.sap.com/
bps_s4. You can also find information about address screening in the application help in the Help Portal.
● Customizing tasks must also be performed specifically for business partner screening in SAP Business
Partner Screening.
If your business system is an SAP system, then you can set up an RFC destination to the SAP Business
Partner Screening system for calling the RFC API. You will also find information about specific customizing
requirements in the online documentation of the RFC function modules in package BCPM_RFC in the SAP
BPS system.
Otherwise, you can use the BusinessPartnerCheck_Request_Sync_In enterprise web service to
request screening of business partner master data.
Function Modules
The RFC version of the API is held in package BPCM_RFC, which you can access with the ABAP Workbench,
transaction SE80, or with the Eclipse-based ABAP Development Tools. You will find online documentation on
the function modules and parameters in your system.
Parameters
For business partner master data screening, the following parameters are used in the function module
BPCM_PARTNER_CHECK:
The RFC API for business partner master data screening offers two levels of implementation. This section
describes the basic option:
● Submitting business partner data to SAP Business Partner Screening for screening
● Receiving information from SAP Business Partner Screening on whether any hits were found in watch lists
● Setting the final status of alerts as confirmed or rejected
To implement this level of integration, you need to call only two RFC function modules from your application:
● BPCM_PARTNER_CHECK submits business partner data for screening against watch lists at SAP Business
Partner Screening.
● BPCM_ALERT_DECISION_CHANGE communicates user decisions on hits against watch lists to SAP
Business Partner Screening, so that alerts can be closed according to whether the hit is valid or is a false
alarm.
This section explains how to use these function modules; for details, see the online documentation of the
function modules in your system.
Implementing calls to these function modules enables not only synchronous name and address screening in
real time in your application, it also enables delta address screening. The business partner data that you
submit with BPCM_PARTNER_CHECK is persisted in SAP Business Partner Screening. As relevant watch lists are
updated, the business partner is automatically included in delta address screening. In delta address screening,
the changes in a relevant list are used to look for new hits against business partners. New alerts from delta
screening are not automatically reported to your business system.
Here in overview is the process for using the BPCM_PARTNER_CHECK and BPCM_ALERT_DECISION_CHANGE
function modules to do business partner screening, present results to the requesting user, and return the
user's decisions to SAP Business Partner Screening:
1. Map your business partner data to the person or organization structures required by SAP Business Partner
Screening and exposed in function module BPCM_PARTNER_CHECK.
2. Call the function module at SAP Business Partner Screening. If you are integrating an SAP business
process, you can use RFC. In this case, you must define an RFC destination in your system that points to
the SAP Business Partner Screening system. Users who call the function module must have role
SAP_BPCM_SYS_COM in the SAP Business Partner Screening system.
If you are calling the function from a non-SAP system or a non-ABAP system, then you can, for example,
expose the BPCM_RFC function modules as enterprise web services at the SAP Business Partner Screening
system. For more information, search for example for ABAP Web Service Wizard.
3. Present the results to your business users at the calling system. Users must decide whether a hit – the
discovery of a business partner in a watch list – is valid or should be ignored.
4. When the user has finished with step 3, you must report the decisions to SAP Business Partner Screening
with the RFC function module BPCM_ALERT_DECISION_CHANGE, unless you have suppressed alert
generation with the IV_SIMULATION_INDICATOR parameter.
Here is sample code showing a call to BPCM_PARTNER_CHECK. Notes follow the example.
By default, alerts are created in SAP Business Partner Screening if a business partner is found in a watch list.
By setting the simulation indicator to 'X', you can suppress the creation of alerts. The function module still
returns hits to you if alerts are suppressed. Simulation is recommended only for test and development
operation.
By default, alerts can be closed by users in SAP Business Partner Screening (IV_INVESTIGATION_IN_BPCM
= 'X'). Clearing this parameter prevents manual change of alert status in SAP Business Partner Screening. In
any case, you must report the results of the user decision on hits to the SAP Business Partner Screening
system in order to close any alerts that have been created (BPCM_ALERT_DECISION_CHANGE).
Fill these tables with the data of the business partners that are to be screened. Please note the following:
● SAP Business Partner Screening distinguishes between business partners who are persons and those that
are organizations.
● You can supply more than one person and/or organization per call with the function module.
● A person or organization may also have more than one address supplied in field ADDRESS in the
IT_PERSON or IT_ORGANIZATION parameter. If there is more than one address, then the person or
organization is presented for screening multiple times, once for each individual address.
● A person is identified by the key fields BUSINESS_SYSTEM, PERSON_TYPE, and PERSON (ID number). See
the online help for parameter IT_PERSON for more information.
● An organization is identified by the key fields BUSINESS_SYSTEM, ORGANIZATION_TYPE, and
ORGANIZATION (ID number). See the online help for parameter IT_ORGANIZATION for more information.
● An address of a person or organization is identified by the key fields ADDRESS_ID, ADDRESS_VARIANT, and
VALID_FROM, where ADDRESS_VARIANT is a type of address from the calling system, such as "place of
birth" or "current residence". ADDRESS_ID, like the PERSON and ORGANIZATION ID fields, must be filled
with leading zeroes if the ID value does not fill the field. The VALID_FROM field constrains the validity only
of the address with which it is associated, as it is not possible to construct from-to durations across
different address variants and ranges within variants are not created.
The address screening feature of SAP Business Partner Screening determines automatically which detection
strategies should be applied to a screening request from BPCM_PARTNER_CHECK.
In order to select detection strategies, you must supply SAP Business Partner Screening with a
BUSINESS_SYSTEM and a COUNTRY_ISO in the ADDRESS entry. Optionally, you can also supply a RISK_LEVEL
from the Customizing in SAP Business Partner Screening, and one or more organizational unit specifications in
the ORGUNIT table parameter. The ORGUNIT values also must be customized in SAP Business Partner
Screening. If you provide an ORGUNIT, then both fields must be filled.
The IV_CHANGE_REQUEST field is for the ID number of a change request for creating or changing the master
data of a business partner. Leave this field empty if you simply want to screen a business partner and do not
use any master data management functions in your source system.
If you supply a value for the IV_CHANGE_REQUEST parameter, then SAP Business Partner Screening saves
your business partner data in draft form. The system assumes that you will separately report the final status of
the change request when it is approved or cancelled. The draft information will then be either saved in status
"active" or is deleted. For more information, see Version Management of Business Partner Master Data:
Implementation with RFC [page 24].
ACCESS_GROUP Authorizations
Results
Business partners are screened separately for each address that they may have. If a business partner has more
than one address, then there may be more than one entry for the business partner in the results table. The
entry is identified by the PERSON or ORGANIZATION ID number. The address is identified by the address key
fields, ADDRESS_ID, ADDRESS_VARIANT, and VALID_FROM. To present a hit with the business partner's name
and the address that triggered the hit, you must read these values from the input parameter tables using the
key fields that have been returned.
For more information, see the online documentation of the *_CHECK_RESULT tables.
Messages
Here is sample code showing a call to BPCM_ALERT_DECISION_CHANGE. Notes follow the example.
To close alerts, you need the ALERT_ID and ALERT_ITEM_ID fields from the *_CHECK_RESULT tables
returned by the BPCM_PARTNER_CHECK function module, above. ALERT_ID is found in the ALERT_DETAILS
structure. ALERT_ITEM_ID is found in the ALERT_ITEM_DETAILS structure in the *_CHECK_RESULT tables.
The ES_RESULT structure reports on the closure of the alerts in SAP Business Partner Screening, including
error messages, such as missing ACCESS_GROUP or other authorizations.
To implement this level of integration, you need to add calls to two additional RFC function modules to your
implementation of business partner screening. These are as follows:
This section explains how to use these function modules; for details, see the online documentation of the
function modules in your system.
Calls to these function modules should be implemented synchronously. There is no need to communicate
decisions on change requests for business partner master data to SAP Business Partner Screening
asynchronously.
At screening, business partner data is saved in the SAP Business Partner Screening system so that it can be
included in delta address screening. In simple business partner screening, business partner data is saved in
status “active”. The API extension described in this section lets you control a versioning system for the
business partner data in SAP Business Partner Screening.
If you supply a change request when you submit a business partner for screening, then the API assumes that
you wish to use the version management part of the API. In this case, the business partner data is stored at
SAP Business Partner Screening in status “draft”. The “draft” version does not affect an “active” version of the
business partner data that may already have been saved in the SAP Business Partner Screening system.
(However, the “draft” version uses the “active” version as a starting point and updates the data from the
“active” version. This ensures that the business partner data is complete if not all of the data is provided with a
change request.) Synchronous screening is performed against the draft version of the business partner data;
any resulting alerts can be found by way of the change request ID that you submitted.
● If the change to the master data of the business partner has been approved, then you call
BPCM_PARTNER_CR_ACTIVATE. At the SAP Business Partner Screening system, the function module
changes the status of the business partner data from “draft” to “active”. Any active version that was
already present is overwritten. Any alerts remain in their current state and continue to be associated with
the business partner.
Especially for the SAP integration of SAP Master Data Governance with SAP Business Partner Screening,
the final PARTNER_ID of the master data also is recorded in the data in SAP Business Partner Screening.
Supplying the parameter for this operation, IT_PARTNER_IDS, is optional. You do not need to use this part
of the API if it does not apply to you. If you need to use this feature, then you must provide a
PARTNER_GUID with the call to BPCM_PARTNER_CHECK. The partner GUID is required for finding the
business partner data in SAP Business Partner Screening after the change from a temporary to a
permanent partner ID.
● If the change to the master data of the business partner has been cancelled (the final status is “completely
withdrawn”), then you call BPCM_PARTNER_CR_ROLLBACK. At the SAP Business Partner Screening
system, the function module deletes the “draft” version of the business partner data. Any alerts generated
for the draft version of the data are closed automatically. Any active version of the data is unaffected.
This part of the RFC API lets you keep the business partner data in SAP Business Partner Screening up to date
with the final status of the data in your business system. It also ensures that alerts are closed, if they were
created for business partner data that has been withdrawn.
To identify the business partner master data in the SAP Business Partner Screening system, you must provide
the name of your source system in SAP Business Partner Screening Customizing, in IV_BUSINESS_SYSTEM.
You must also provide the change request ID that you submitted with BPCM_PARTNER_CHECK. The activation
affects all t business partner names and addresses that were submitted with the change request ID. All are
saved as "active" information.
Optionally, you can provide final partner IDs in IT_PARTNER_ID. This is required only if you must adjust the
final ID, as is the case in the integration of SAP Master Data Governance with SAP Business Partner Screening
for business partner screening.
Results
The API returns the business partner data that was affected by the change approval or cancellation.
BPCM_PARTNER_CR_ROLLBACK closes all alerts associated with the change request ID. The final status of the
alerts is “not investigated”.
As an alternative to the RFC interface, you can request business partner screening by calling the
BusinessPartnerCheck_Request_Sync_In enterprise web service at the SAP Business Partner Screening
system. Point to point communication is enabled, so that no Process Integration (PI) system is needed as a
hub. You can find the service in package BPCM_SERVICE.
Input and output structures of the service are similar to those of the RFC API (for more information, see RFC
Function Groups, Function Modules, and Parameters [page 17]). Execution of address screening of business
partners is identical to that of the RFC API, with the exception of internal web service specialties, such as the
mapping of web parameters to internal data structures.
For:
● Inbound mapping of the enterprise service repository input to the data structures used by the API (as
described with respect to the RFC interface); and
● Outbound mapping from internal data structures to the ESR output
For more information, see Creating and Configuring Service Providers and Service Consumers.
SAP Business Partner Screening offers easy-to-use support for adding customer fields to the programming
APIs for business partner screening (see Implementing the Interface for Business Partner Master Data
Screening [page 15]) and for business transaction screening (see Business Transaction Screening [page 4]).
You can add fields to both the RFC programming interfaces and the counterpart of business transaction
screening in enterprise services. The first step in any case is to add customer fields to the RFC programming
interfaces; this is a prerequisite for adding fields to web messages. Adding fields to the RFC APIs modifies the
internal structures of the APIs. Adding fields to the messages modifies the external message formats and
requires mapping to the internal structures.
The procedures for adding fields to the RFC programming interface and to enterprise service interfaces are
different and are described separately in the following sections.
To add customer fields to the RFC APIs, you need only do the following customizing tasks:
● Add the fields to the field catalog in the Customizing of SAP Business Partner Screening.
● Identify the fields as enrichment fields or selection fields in the Customizing for SAP Business Partner
Screening.
SAP Business Partner Screening automatically takes care of adding your fields to the internal data structure
and generating the necessary local SAP HANA views.
For instructions, see Adding Customer Fields to the RFC APIs and Internal Structures [page 28].
To add customer fields to a web message, you must first add corresponding fields to the RFC API for business
transaction screening, as described above. Then you must do the following tasks:
This section explains how to add your own fields to the internal data structures and RFC interfaces of these
screening interfaces:
● Business partner screening (see Implementing the Interface for Business Partner Master Data Screening
[page 15])
● Business transaction screening (see Business Transaction Screening [page 4])
Adding fields to this RFC API is a prerequisite for adding fields to the web service API for business
transaction screening (see Adding Customer Fields to the Web Service for Business Transaction Screening
[page 32].)
Do the following:
1. In your SAP Business Partner Screening system and client, start customizing activity Define Source
Domains for Screening.
Note that you should use only a single Source Domain for all SAP and Customer fields in the field catalog.
We recommend using the standard BPCM source domain.
3. For each field that you wish to add, click New Entries and fill out the New Entries dialog.
Only the Field, Description, and Data Type fields are required. You can add fields of any data type.
Result: Your new fields are ready for use in RFC requests for screening. The system automatically adds the
fields to the extend structures for customer use. The change becomes effective (the field is actually added) the
next time that the affected object type is used. The system also automatically generates the local SAP HANA
objects needed for using the fields.
Review the changes that you have made and verify that all objects have been generated successfully by using
the monitor transaction that is described in the next section. If you are extending the web service interface for
business transaction screening, you can now add your new fields to the service. See Adding Customer Fields to
the Web Service for Business Transaction Screening [page 32].
SAP Business Partner Screening automatically does the activation necessary for you to use your new fields.
But transaction BPCM_GM_BO offers a fast and convenient way for you to see SAP and customer enrichment
and selection field assignments and the status of generation. You can also generate changes to enhancement
include structures and SAP HANA views manually, as a supplement to the automatic system generation.
Panel Information
Customer Fields Offers lists of all enrichment and selection fields, respec
tively, that have been defined for investigation and detection
objects of SAP Business Partner Screening.
System Status and message log Shows the current status of generation of investigation and
detection object types.
If you delete a field after you have added it, then it is removed automatically from SAP HANA objects, but it is
not deleted from the extension includes to which it has been added. Deleting a customer field from the
extension includes is a manual task.
Caution
Fields cannot be deleted from the includes automatically because of the risk of data loss. If you have been
storing data that uses the field that is to be deleted, then deleting the field will make the data unusable.
This section explains how to add your own fields to the web service interface for business transaction
screening. For more information about this API, see see Business Transaction Screening [page 4].
Prerequisite: You must add your new fields to the internal data structures used by business transaction
screening, as shown in Adding Customer Fields to the RFC APIs and Internal Structures [page 28].
The procedure for adding fields to the enterprise service interface consists of two main tasks:
1. Enhancement of the enterprise service provider with your new fields and generation of the required proxy
objects.
2. Implementation of a BAdI (Business Add-In) for mapping from the web service message to internal data
structures.
After you have completed these tasks, then your enhanced web service is ready to use.
1. Adding your own fields as an enhancement to the standard service for business transaction screening:
BusinessTransactionCheck_Request_Sync_In in package BPCM_SERVICE.
2. Generating proxy objects for the enhanced service in transaction SPROXY.
3. Implementing the BAdI BPCM_BADI_SE_BT_DETECTION of enhancement spot
BPCM_BADI_SE_DETECTION. This BAdI maps from the fields in the web service message to the
corresponding fields in the internal data structures. (You added fields to the internal data structures as a
prerequisite to enhancing the web service).
You can maintain the BAdI in the customizing activity BAdI: Enhance Detection Service for Business
Transaction Screening.
The implementation work that you need to do in the Enterprise Services Repository and Enterprise Services
Builder breaks down into these two tasks:
1. Adding your own fields as an enhancement to the standard service for business transaction screening:
BusinessTransactionCheck_Request_Sync_In in package BPCM_SERVICE.
Note
You will have to fill new fields in the outbound message yourself. Since the output structure of the
internal API used by the service cannot be extended, you must fill any new output fields from the
standard output of the API, for example, by calculating with the standard output.
You can find how-to instructions for doing these tasks in the Enterprise Services Enhancement Guide. You can
find this guide on the SAP Community at http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/
uuid/c0bb5687-00b2-2a10-ed8f-c9af69942e5d?QuickLink=index&overridelayout=true&31486405274530 .
You can maintain the BAdI in the customizing activity BAdI: Enhance Detection Service for Business Transaction
Screening.
In the BAdI, you need only implement the INBOUND_PROCESSING method, as customer fields are not returned.
The INBOUND_PROCESSING method receives the inbound message fields in input/output parameter
IS_BT_CHECK_REQUEST. You need to map your new fields in IS_BT_CHECK_REQUEST to the new internal
fields that you have defined in CS_API_INPUT.
The application provides capabilities for globalizing message texts. That is, you can output message texts in the
language of the current user. And you can apply localized formats – appropriate for the current user – to
message variables that contain information such as numbers, amounts, or dates and times.
The messages that can profit from these globalization capabilities include the following:
● Message texts created in the Execution or Additional Information procedures of SQLScript detection
methods. These messages explain detection results and are displayed to users in alert details.
Using the message globalization capability in detection methods requires that you provide additional
values for fields in the ET_TEXT output parameter.
Both the Execution and Additional Information procedures can provide messages. Generally, however,
messages are issued only from the Additional Information procedure, in which case setting messages from
the Execution procedure is optional.
Functional Overview
The application provides for translatability of the messages listed above by allowing detection methods to
identify a T100 message for each type of message that is to be returned. The central infrastructure in AS ABAP
sees to it that the referenced T100 messages are displayed to each user in the language of the user, provided
that a translation of the message in the required language is available in the system. Otherwise, standard AS
ABAP fallback mechanisms for message display come into play.
Localized formatting of amounts, dates and times, and numbers is provided by allowing you to reference a field
defined in Customizing activity Define Source Domain and Field Settings as the template for formatting.
The Execution and Additional Information procedures of a detection method specify T100 messages and field
settings as formatting templates in their ET_TEXT output parameters.
In SAP Business Integrity Screening the Procedures Wizard and the Test Procedure for Mass Detection
transactions automatically include the message parameters in ET_TEXT. During the generation of detection
method wrappers and strategy procedures the signatures of the rule procedures are read. If the new fields are
not included in the output parameter ET_TEXT, then the detection method wrapper adds them. So in the end
all generated wrappers have the same interface and can be used in one and the same strategy.
You can continue simply to provide a fixed text to ET_TEXT-TEXT instead of using globalized messages, so that
you do not need to change the implementation of existing views and procedures.
Example
A detection method that uses the new translation and localization capabilities specifies the T100 message and
fields for formatting in new fields in the ET_TEXT output parameter. Assume that the ET_TEXT output looks
like this:
MSGID = 'MY_MSG_CLASS'
MSGNO = '001'
MSGV1 = '1500'
MSGV1_FC = 'CURRENCY_VALUE'
The MSGID and MSGNO parameters identify the T100 message that will be presented to users. (For more
information, see transaction SE91).
The T100 message definition includes two named variables, for which the values 1500 and EUR are provided.
These values will be formatted for insertion into the message according to the properties of the fields
CURRENCY_VALUE and CURRENCY in the Customizing for source domain SOURCE_DOMAIN_1.
More Information
You can enhance the user interfaces of your application in several ways. You can add new apps and tiles to your
application. You can extend some of the standard SAP Fiori apps. And you can tailor the Network Analysis
section of the Manage Alerts app for displaying the data with which you want to work.
SAP Fiori apps are displayed on the home screen as tiles. You can add apps and expose them as tiles to provide
your users with new functions.
For more information, see Creating Additional Apps and Tiles for the SAP Fiori Launchpad [page 38].
Note
● The All Things SAP Fiori landing page at this URL in the SAP Community Network (SCN): http://
scn.sap.com/docs/DOC-41598
● Extending UI at SAP Fiori Extensibility collaborative document in SCN: http://scn.sap.com/docs/
DOC-53177 and View Extension in the documentation of User Interface Add-On for SAP NetWeaver
on the SAP Help Portal (http://help.sap.com/saphelp_uiaddon10/helpdata/en/
40/3c050da4ae4566b6aafec2bc590389/content.htm )
● Extending OData at the SAP Fiori - OData/Gateway collaborative document in SCN: http://
scn.sap.com/docs/DOC-61828
You can extend Manage Alerts, the new workplace for investigating and closing alerts, with new fields and new
tools.
For more information, see Extending the Manage Alerts App [page 38].
The network analysis tool is a powerful way to analyze relationships between entities through visual display. For
example, you could display the network of business partners and orders involved in a set of questionable
purchases.
For more information about equipping the tool for the network displays that you need, see Extending the
Network Analysis [page 49].
You can add your own tiles and apps to the SAP Fiori launchpad.
To do so, open the SAP Fiori Launchpad Designer, and do the following:
1. In your back-end system, log on to the client of your solution and open the Customizing by entering
transaction FRA_IMG.
2. Open Customizing activity SAP Fiori Launchpad Designer (Current Client).
The SAP Fiori Launchpad Designer opens to the catalogs and groups that are available. You can add new
tiles and apps that you create to the catalogs and groups. See the documentation cited in the next
paragraphs.
To create a new SAP Fiori app, use the SAP Web IDE. For more information, see for example Getting Started
with SAP Web IDE .
To add an app to the SAP Fiori launchpad as a new tile, use the SAP Fiori Launchpad Designer. For more
information, see Using the Launchpad Designer.
As you add apps and tiles to the SAP Fiori Launchpad, we recommend that you follow the best practices
described in Best Practices for Setting Up Content in User Interface Add-On 2.0 for SAP NetWeaver.
The Manage Alerts app is intended to be the workplace for investigators. With this app, investigators can track
and document their work on alerts.
This section explains how to add your own fields to the Manage Alerts app.
The first step in adding a customer field to alerts in Manage Alerts is to extend the FRA_ALERT business object.
If you are migrating fields that you have already added, you can skip this step; it is already done.
Do the following:
1. Start transaction BOBF and open the FRA_ALERT business process object.
2. Open the ROOT node structure and double-click to navigate to the edit screen of the Extension Include,
INCL_EEW_FRA_BO_ALERT_ROOT. Add the new field to this structure, save, and activate.
Adding a field to the FRA_ALERT object extends the FRA_D_ALERT_ROOT table. For more information, see also
Adding Customer-Defined Fields to Business Objects [page 40].
Once your new field has been added to the FRA_D_ALERT_ROOT table, you can modify the CDS views that read
alerts. You do this by modifying two special CDS views that extend the operational views.
Use ABAP Development Tools to modify two extension views in the sequence shown below. Add only the new
fields to the extension views, no other code.
● FRA_CV_AlertRoot_ExtensionIncl
● FRA_CV_AlertRoot
Sample code for adding a field called zzextension_field to the first extension view looks like this:
RootExtension is required. The field name is determined by your addition to the extension include of the
FRA_ALERT business object. The sqlViewAppendName is again yours to choose.
RootExtension is required. The field name is determined by your addition to the extension include of the
FRA_ALERT business object. The sqlViewAppendName is again yours to choose.
After the two views shown above have been activated, you must clear the OData cache. You do this by running
the following customizing activity: SAP NetWeaver SAP Gateway OData Channel Administration
Cache Settings Metadata Clear Cache .
Once the cache has been flushed, the field that you have added is automatically made available in the OData
representation of the Alert Root. Your users can include the field in the alert list by selecting the new field in the
alert personalization. The display might look something like this, where Checkpoint Med is the name of the new
field. Users can access personalization services by way of the button highlighted in yellow.
The figure below shows a new field, Checkpoint Med, in the list of alerts. Users must select the field for display
in the personalization services, which are accessible by way of the button marked in yellow.
You can add customer-defined fields to alerts, detection methods, personal settings, and detection strategies.
Procedure
Follow these steps to add new fields to a business object data model:
1. Go to transaction BOBF, expand the node Transportable Business Objects Business Process Objects
2. Double-click an FRA_* business object to display the details.
For alerts, double-click FRA_ALERT. Other extendable business objects are FRA_DETECTION_METHOD,
FRA_PERSONAL_SETTINGS, and FRA_STRATEGY.
3. Expand Node Elements and choose a node for extension that meets these conditions:
1. The node offers an extension structure.
2. The node does not have any Queries that reference SAP HANA views (HANA View field in the Query tab
of an expanded query).
Caution
You can add to the extension include in a node that uses SAP HANA queries. But in that case, you must
copy and modify the SAP HANA view referenced by each query to support the new component.
Otherwise the queries no longer work. Exception: If the extension include is not included in the
Combined Structure of the node element, then new components in the extension include do not affect
the SAP HANA query.
If you create a replacement view, then you can use the SAP HANA studio to copy and replace the view
in the business object.
4. The right side of the screen shows the details of the node. Find the Extension Include field under the Data
Model section. Double-click the structure name in the text field to go to the Dictionary: Display Structure
screen.
5. In the structure display in the ABAP Data Dictionary (transaction SE11), choose Goto Append
Structure to add components to the extension include.
Using an append structure is recommended so as to avoid modifying the extension include. You do not
need to edit the extension include, nor do you need to reactivate it after adding the append structure, nor
do you have to regenerate the business object.
6. After the append structure has been added, you need to clear the cache so that the new fields can
potentially be seen on the UI. To do so, use transaction FRA_CLEAR_BUFFER or complete the following
activities:
○ Open customizing activity Clear Cache, and choose Execute.
○ Open customizing activity Clear Cache
The data model of alerts is predefined in the application. However, the application offers several ways to add
data to alerts, should you need to do so to help your investigators process them. The following sections explain
these options. In this section, only reuse of replicated data is considered.
The predefined alert data model lets you add additional data fields to an alert. You can add any fields that are
exposed by the SAP HANA enrichment view that is specified for an investigation object type.
For more information, see the customizing activity Define Investigation and Detection Object Types for
Screening.
More Information
For more information about extending the alert data model, see Adding Customer-Defined Fields to Business
Objects [page 40].
If you develop new alert investigation tools for Manage Alerts, then you should implement these as SAP Fiori
component-based sections. This documentation explains how to implement component-based sections in the
context of the Manage Alerts app. You can find SAP Fiori documentation on component-based sections in the
SAP Help Portal under this URL: http://help.sap.com/saphelp_nw75/helpdata/en/
95/8ead51e2e94ab8bcdc90fb7e9d53d0/content.htm
Implement a tool for alert investigation in the Manage Alerts app as a SAP Fiori UI component (parent class:
sap.ui.core.UIComponent).
The sample code below shows the required and optional parts of a component in the context of the Manage
Alerts app. For information about building the component, instantiating the OData service for the component,
setting up the UI, see the SAP Fiori Component documentation cited above or the detailed instructions at the
end of this document.
return UIComponent.extend("Your_BSP_Project.Component", {
// required UI setup
createContent : function() {
// create UI
},
// required current-alert processing (setAlertDBKey function)
setAlertDBKey : function(sAlertDBKey) {
// Use AlertDBKey Parameter for reading data
return this;
}
});
});
Component Definition
As the opening lines of coding show, you define your component-based section as a UI component, extending
the class sap/ui/core/UIComponent. Name your component with the path name of the Business Server
Page application (BSP application) to which it belongs, ending the path name with a freely selectable
component name. In the example above, the name is simply Component.
In the metadata section of your component, you must define a string attribute with the name AlertDBKey.
Manage Alerts passes the database key of the current alert to your section with this attribute.
Your section is initialized only once, when Alert Details in Manage Alerts is first called. After initialization, your
section is called in-place to display the data of the alert that is currently active in Alert Details. You must
therefore use the AlertDBKey attribute to read the data of the current alert and refresh your UI each time your
section is called.
SAP Fiori automatically generates a "set" function (setAlertDBKey in the example above) for the
AlertDBKey attribute. Manage Alerts calls this function each time your section is called (by a user clicking on
the section name in the tool bar) in order to give your section the database key of the current alert.
Since this function is called every time that your section is called, you can use this function to update your UI
with the data of the current alert. You can overwrite this function, as done in the example above, to react to the
call, read the current alert data, and refresh the UI before it is presented to the user. It is important to store the
parameter value passed into the set function in the AlertDBKey attribute; otherwise, you cannot access it
outside the context of this function.
You can freely choose the name of the parameter that is passed to this function by Manage Alerts. In the
example, the parameter is called sAlertDBKey.
Since the function is called only once, you should use this one-time setup of your user interface to initialize the
UI. Refresh the UI with the data of the current alert in the setAlertDBKey function.
Once you have finished implementing your new component-based section, you must maintain these two
customizing activities to make the section available in Manage Alerts:
For more information, see the online documentation of the customizing activities.
This procedure shows how to develop a section using the ABAP Workbench. You can also develop a section in
the SAP Web IDE and deploy it to the back-end system of your application.
1. Start the ABAP Workbench (transaction SE80) and create a new BSP application.
2. In your BSP application, create a new page with flow logic. Name the page Component.js.
3. Enter the sample coding for a section, shown at the start of this document, into Component.js. Complete
the section with your own logic.
4. Open the properties of your BSP application and set the Application Class to /UI5/
CL_UI5_BSP_APPLICATION.
5. Activate the BSP application and Component.js.
Customizing
1. Define your new section in the customizing activity Define Alert Detail Section. Set the Category to SAP UI5
Component-Based Section.
In Component-Based Section, enter names of your choosing for the semantic object and action.
In View-Based Section, set the View Name field to . . Set URL to #<Semantic_Object>-<Action>,
substituting your values for Semantic Object and Action into the URL fragment. Leave View Type empty.
Result: Your section will now be displayed for alerts and can be called for an individual alert.
With release 1.2 SP01, SAP Assurance and Compliance Software introduces Manage Alerts, a SAP Fiori app
that provides a workplace for investigating and completing alerts. The app replaced the Alert ThingInspector as
of release 1.2 SP02 as the workplace for resolving alerts.
1. You have upgraded from a release lower than release 1.2 SP02; and
2. You have programmed your own facets for the old Alert ThingInspector. You would now like to reuse those
facets as SAP Fiori sections in the Manage Alerts app.
Existing ThingInspector facets will not work correctly as sections in Manage Alerts, but can be easily converted
to work correctly.
This section explains how to migrate non-SAP facets from the Alert ThingInspector to the new Manage Alerts
app. We assume in this section that such facets are implemented according to the SAPUI5 view-controller
model.
SAP recommends that new sections are implemented as SAPUI5 components, but existing SAPUI5 view-based
facets can be reused as sections without being rewritten as component-based sections.
Just like facets, SAP Fiori sections in Manage Alerts are tools for alert investigators to use. Unlike facets,
sections are started only once and are then called in-place in Manage Alerts. In the old ThingInspector
architecture, facets were started fresh and initialized in a new browser tab every time they were called.
This difference in the way sections are started is the reason why ThingInspector facets must be modified in
order to run properly in Manage Alerts. Facets in the Alert ThingInspector expect to be initialized every time
that they are called. Sections, by contrast, must be able to refresh themselves when they are called. A facet
might be given the database key of the alert that it is to display every time it is started. A section in Manage
Alerts must be able to receive a new alert DB key and refresh the alert data without being restarted when it is
called.
sap.ui.controller("myApp.detail", {
...
//Required change
setAlertDBKey: function(sDBKey){
...
//Update UI with new Alert
...
}
});
Required is a function in the controller part of your facet with the name setAlertDBKey.
setAlertDBKey: function(sDBKey){
//Alert DB Key is a 32-Char GUID
//Sample key: 047D7B8B-FE39-1ED4-BA9C-D4A3717A062D
//Update section
};
This function must have a parameter that accepts an alert DB key: setAlertDBKey: function(sDBKey).
You may choose a name for this parameter as you wish. In this function, you must read the alert that is to be
displayed and update all of the information that your facet/section displays.
The setAlertDBKey function in each section is called by Manage Alerts each time the Alert Details are opened
for an alert. If the function is present in a particular section, then it should refresh the data in the section using
the data of the current alert. If the function is not present, then Manage Alerts starts your section in-place
anyway, if the user clicks on the section button in Alert Details. But Manage Alerts was not able to pass the
database key of the current alert in to your section, since setAlertDBKey could not be called.
Once you have finished implementing your new component-based section, you can check that these two
Customizing activities have been maintained correctly. These activities make the section available in Manage
Alerts, and are automatically provided with default Customizing for existing facets at upgrade :
Related Information
You can add fields to the alert details in the Manage Alerts app at two places. The following sections document
the extension points.
You can add fields to the alert details header. The following figure shows the header information of an alert for
an insurance claim.
The table below specifies the extension point to use for adding fields to the alert details header.
UI
You can add fields to the Info section, which provides administrative details on an alert. The figure below shows
the Info display for an alert for an insurance claim.
UI
After you have changed the SAPUI5 repository in your SAP NetWeaver system through changes to the user
interface of your application, you may need to update the SAPUI5 application index in your SAP NetWeaver
system.
For more information, see SAPUI5 Application Index in the SAP HANA help portal.
Use
The Network Analysis visualizes the relationships of entities to enable investigators to identify suspicious or
non-compliant constellations.
For example, a display for insurance investigators might show the relationship between claims and claimants,
showing unexpected relationships.
Data for nodes and edges can be provided from SAP HANA views, ABAP-Managed Database Procedures
(AMDP), or ABAP classes. These have to be developed. This is explained in the following section. For
implementation examples of SAP HANA views, see the views in SAP HANA package sap.hana-
app.fra.cm.sna.
Data Providers
Network graphs consist of nodes that are connected by edges. Both can be provided from SAP HANA views,
such as calculation views, ABAP-Managed Database Procedures (AMDP), or ABAP classes. These data
Use the Customizing activities Define Node Types for Network Analysis and Define Edge Types for Network
Analysis to set up new types of nodes and edges and connect them to their data providers. In field Data
Provider Type, choose the kind of data provider you want to use. Depending on the type, either enter the name
of a package and view in SAP HANA, or the name of an ABAP class.
Use SAP HANA views, AMDP, and ABAP classes in this order of preference. Choose SAP HANA views as default
as they are fastest, easiest to develop, and most versatile. Complex scenarios may require calculating edges in
an expensive way, depending on the connected nodes; these cases can be solved by AMDP. Resort to ABAP
classes only for use cases that cannot be provided by the database, such as retrieving data via a Remote
Function Call (RFC) to another system.
To use an SAP HANA view as data provider for nodes in the Network Analysis, it must provide its data in the
following format. The view must provide at least one of the columns ID1 to ID15. All other columns are
optional and may be omitted if not needed.
● BUSINESS_SYSTEM, typed as NVARCHAR(60). The identifier of the business system, if you use cross-
source business objects, for example, your replicated business data stems from multiple replication
sources.
● ID1 to ID15, typed as NVARCHAR(40). The up to 15 IDs that together form the unique key of the node.
● LABEL, typed as NVARCHAR(255). The text that will be shown under the node, for example, the description
of a business document. The field may be calculated from one or more fields in the business data, for
example, to assemble the name of a person of multiple separate name fields.
● STYLE, typed as NVARCHAR(15). The identifier of a node style, see Customizing activity Define Node Styles
for Network Analysis if you want to override the default node style of the node type. For example, you could
specify that the node type ZBUSINESS_PARTNER uses a node style with a neutral image as default, and
make nodes use node styles with male or female images if gender information is available.
● IMAGE_URL, typed as NVARCHAR with length as needed. The URL of the image or icon font symbol to use
for the node. See field Image Location in Customizing activity Define Node Styles for Network Analysis for
possible formats.
For edges, the SAP HANA view must provide its data in the following format. The view must provide at least one
of the columns SOURCE_NODE_ID1 to SOURCE_NODE_ID15, and at least one of TARGET_NODE_ID1 to
TARGET_NODE_ID15. The used columns must fit to the connected node type. For example, to connect a node
type that uses ID2 and ID4 as source node, your edge view must provide exactly the columns
SOURCE_NODE_ID2 and SOURCE_NODE_ID4. Unused columns may be omitted.
To use an ABAP-Managed Database Procedure (AMDP) as a data provider for nodes or edges, create a new
ABAP class that implements the interface IF_FRA_SNA_AMDP_NODE_PROVIDER or
IF_FRA_SNA_AMDP_EDGE_PROVIDER. The interfaces each contain a method that enables the Network
Analysis to instantiate the data provider, and another method that is called to retrieve the nodes and edges.
Implement the READ_NODES and READ_EDGES methods with the statement METHOD <method name> BY
DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT<list of used database tables>. This
makes ABAP generate SAP HANA procedures from them. The code in the method body is SQLScript.
ABAP Classes
To use an ABAP class as data provider for nodes or edges, create a new ABAP class that implements the
interface IF_FRA_SNA_CLASS_NODE_PROVIDER or IF_FRA_SNA_CLASS_EDGE_PROVIDER. The interfaces
each contain a method that enables the Network Analysis to instantiate the data provider, and another method
that is called to retrieve the nodes and edges. The interface documentations provides more technical details.
Identifiers
The IDs returned by the data providers are used to identify the visual elements in the resulting HTML
document, in combination with CSS-, jQuery-, and D3-based element selectors. This may cause problems
when using IDs that contain special characters such as “/” or “#”. Limiting IDs to the HTML-compatible
character set A-Z, a-z, 0-9, hyphens, and underscores, guarantees that the data can be displayed correctly. If
your IDs contain special characters, for example, if you have nodes that represent locations such as “Corner
5th/9th”, consider removing or replacing the special characters.
If you need to identify entities that have IDs with more than 40 characters, you can split the IDs and distribute
them over two or more of the ID fields. An alternative is hashing the ID, for example, with the SAP HANA
function HASH_SHA256, which will convert strings of any length to a 32-character hash; however, mind that
hashes are less unique and this may lead to wrong connections.
Origin Node
When setting up a new Network Analysis scenario, one of the first tasks is to identify the origin node that shall
be displayed in the center of the network graph. The BAdI: Origin Node for Alerts in Network Analysis lets you
specify what node shall be displayed as origin node for a given alert. For example, in an alert for an insurance
claim, you may decide that the origin node shall be the claim, or the claim’s claimant, or the damaged object
and so on
The active default implementation of the BAdI assumes that you have a node type that corresponds to the
investigation object type of the alert. If this is the case, you can use the Customizing activity Map Investigation
Graph Depth
By default, the Network Analysis will attempt to expand two layers of nodes and edges around the origin node.
We chose this value because two is the minimum depth that is required to reveal a cycle in the graph, one of the
core ideas in the pre-configured insurance demo.
You can override the graph depth by replacing the active default implementation of the BAdI: Network Analysis
Graph Depth. Depending on your use case, you may want to choose different graph depths for different alerts,
for example, to expand person networks only by two layers, but business document networks by four layers.
Mind that higher values can quickly lead to cluttered and therefore unusable visualizations. It may be better to
choose a low initial value and rather let the user expand deeper layers as needed.
Authorization
Assigning node types and edge types to an ACCESS_GROUP gives you authorization checks on category basis. If
you need to check authorizations on instance basis, you can implement the BAdI: Authorization Checks for
Network Analysis. The BAdI enables you to remove single nodes and edges that the user is not authorized to
see.
There is no generic content delivered for Network Analysis, however, the output structure must be the same for
all the SAP HANA information models for Network Analysis.
Output Structure
To serve as a source for nodes, an SAP HANA information model must return output with the following
structure:
ID5 NVARCHAR 40
To serve as a source for edges, an SAP HANA information model must return output with the following
structure:
SOURCE_NODE_ID5 NVARCHAR 40
TARGET_NODE_ID1 NVARCHAR 40 Key of the node the edge ends in. See
SOURCE_NODE_ID1-5.
TARGET_NODE_ID2 NVARCHAR 40
TARGET_NODE_ID3 NVARCHAR 40
TARGET_NODE_ID4 NVARCHAR 40
TARGET_NODE_ID5 NVARCHAR 40
For both nodes and edges, the data types do not have to match exactly but must be compatible. It is possible to
use shorter fields, reduce the precision from Unicode to ASCII characters or even change the data type to a
numeric one. However, this is error-prone and not recommended.
The information model may return more columns, but these are ignored. This may allow you, for example, to
use the same information model as a data source for investigation or detection objects or in a detection
method.
The information model should not produce duplicates. Graph display will still work but may become noticeably
slower because of the exponential buildup of the number of nodes and edges that need to be retrieved and
traversed.
This section explains how you can use SAP HANA views and Microsoft Excel to analyze SAP ERP source data
and alerts from your application. You can save your analyses as spreadsheets.
Prerequisite
● Download and install the SAP HANA Client for Excel from the SAP Support Portal http://support.sap.com/
swdc Software Downloads By Alphabetical Index (A-Z) .
● Ensure that you have an SAP HANA user that is authorized to access the SAP standard views and any
additional views that you create yourself.
1. Start Microsoft Excel and start the Data Connection Wizard: Data From Other Sources From Data
Connection Wizard .
2. In the Data Connection Wizard, choose Other/Advanced and then SAP HANA MDX Provider.
3. Enter your SAP HANA connection and logon data to log on to the SAP HANA database.
4. Select a view to use. The view provides the data that you want to analyze.
1. You can select the SAP standard view AN_ALERT_VIEW (package sap.hana-
app.fra.generic.ana) to analyze alerts generated by the application.
Note
You can also use views from SAP ERP to analyze the ERP data during alert investigation, provided
that you have the system information, view name, and in which package it is located.
Use the views listed above as starting points for your own views for analysis.
Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:
● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your
agreements with SAP) to this:
● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.
● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.
● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such
links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this
information.
Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax
and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of
example code unless damages have been caused by SAP's gross negligence or willful misconduct.
Gender-Related Language
We try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.
SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.
Run Simple