General System Features

1 Introduction

This guide contains key information to setup Manufacturing Sales Platform (MSP) general system features effectively. The guide provides the concepts and detailed definition of the functions, aiming to enable administrator to have sufficient knowledge to setup the function with minimal supervision.

The document will be continually edited and updated based on latest product releases. Taking into the consideration of expensive effort keeping the document updated and effective usage of it, only major and complex features should be covered.

To better illustrate how to setup certain feature, some examples are given. It also contains the steps linked to relevant screens. Each step contains actions which the administrator needs to perform to complete the setup.

This administration guide is based on Manufacturing X (MX) release version 1902.

Enjoy!

The Product Engineering Team

2 General Ontology and Property File Management

MSP uses certain files to provided system-specific properties and ontology-based customization of the system. These files are maintained under Administration -> Content Management -> folder conf.

This conf folder is an MSP need and should not be renamed in an implementation, it won’t hurt the system if done, but the system would reset to its default configuration, and the property and ontology file configuration would be ignored.

2.1 Product Sync Procedure

To access uploaded or to create new files go to Administration è Content Management, as shown below.

Three different type of files are highlighted in above screenshots these are:

  • *.properties files: the general property files for MSP: application.properties and email.properties
  • *.n3 files: location mapper files to find the right .owl files.
  • *.owl files: the ontology files in, /conf/ontology folder

2.1.1 Properties files

The main properties file for MSP is: application.properties file. This file contains the base properties that can be used to configure/setup an MSP system.

Any change to this file needs a download of the file from server, update in your local system and upload back to the server. Once done the tenant/application on cloud platform needs a restart to make effect the changes.

Important properties in the application.properties file, the left side is the key and the right side is the explanation of those keys and not the real keys :

# Product Name

  • com.imc.webapp.app.inmindcloud.product.name= example “MSP”

#CMIS Setting

  • com.imc.webapp.app.custDataLoc= example “cmis:”

 

# Cloud for Customer Setting

  • com.imc.webapp.app.keystore.password= password of the certificate for cloud for customer connection
  • com.imc.app.iss.integration.cfcUrl= the cloud for customer system url ex: https://my308286.crm.ondemand.com
  • com.imc.webapp.app.id.remote.businesssytem= the business system configured in SAP CFC for MSP purpose
  • spring.profiles.active= noLegacyACLs,noTriggeredQueries, disableFuzzySearch,

 

SSC

  • noLegacyACLs: the User Role GA based access control, deprecated only left for legacy purpose
  • noTriggeredQueries: disables the usage of triggered sparql, to be maintained in case triggered sparqls are not used
  • disableFuzzySearch: disables fuzzy search, however product search in catalog is already exact

SSC: in case SSC is used as the configuration and pricing engine.

#SSC related properties

  • com.imc.webapp.app.ssc.enabled=true, true or false in case SSC needs to be enable
  • com.imc.webapp.app.ssc.ppwhitelist=ZPQ12, the name of the pricing procedure that SSC needs to pick
  • com.imc.webapp.app.ssc.jars= The jar file, if any, for SSC user exits
  • com.imc.iss.monitoring.recipients=email id of the support team/person to receive automatic exception email

 

# enable database backend

  • com.imc.webapp.app.db.enabled=true, should be by default this only
  • com.imc.webapp.app.customer.namespace=not in use anymore
  • com.imc.webapp.app.extension.namespace=http://www.inmindcloud.com/application/application-schema-ext.owl, default and should be kept to this path only.
  • com.imc.webapp.app.rootOntology = http://www.inmindcloud.com/application/products/products-rule.owl, defunct property.
  • com.imc.webapp.app.locationMapping = cmis:/conf/location-mapping-to-empty.n3, default and should be kept to this only
  • com.imc.webapp.app.public.url = https://isscustomername123456e.hana.ondemand.com/iss/ , the public url of the tenant

 

#autodesk forge API credentials

  • autodesk.client_id=autocad client id useful for autocad connection from MSP
  • autodesk.client_secret=secret key generated in autocad side
  • autodesk.engine_version=20.1, example engine level

 

#order splitting

  • salesordersplit.orderItemThreadshold=the number of items for which sales order needs to be split
  • salesordersplit.nosplitSalesOrg=the sales org for which sales order should not be split

 

email.properties

  • MSP uses this properties file to connect to a mail account for ending notification emails.
  • Parameters of this property file:
  • mail.pop3.host=outlook.office365.com
  • mail.pop3.port=995
  • mail.pop3.ssl.enable=true
  • mail.smtp.host=smtp.office365.com
  • mail.smtp.port=587
  • mail.smtp.auth=true
  • mail.smtp.starttls.enable=true
  • [email protected]
  • mail.smtp.password=
  • [email protected]
  • [email protected]
  • mail.system.password=

 

email-content.properties

This property file provided the keys to customize the text of notification emails such as approval and routing emails. Below is the example:

  • workItem.approval.needed.title=Approval needed for ${doc.type} “${doc.objectName}”
  • workItem.approval.needed.content=Dear ${user.objectName},\n\nYour approval for ${doc.type} “${doc.objectName}” is needed. Please review the document at ${doc.url}.\n\n\n———-\nThis is a system generated message. Please do not reply to this email.
  • workItem.approval.cancelled.title=Approval request cancelled for ${doc.type} “${doc.objectName}”
  • workItem.approval.cancelled.content=Dear ${user.objectName},\n\nThe request for your approval of ${doc.type} “${doc.objectName}” is cancelled.\n\n\n———-\nThis is a system generated message. Please do not reply to this email.
  • workItem.approval.approved.title=${doc.type} “${doc.objectName}” is approved
  • workItem.approval.approved.content=Dear ${user.objectName},\n\nYour approval request for ${doc.type} “${doc.objectName}” is approved. Please review the document at ${doc.url}.\n\n\n———-\nThis is a system generated message. Please do not reply to this email.
  • workItem.approval.rejected.title=Approval for ${doc.type} “${doc.objectName}” is rejected
  • workItem.approval.rejected.content=Dear ${user.objectName},\n\nYour approval request for ${doc.type} “${doc.objectName}” is rejected. Please review the document at ${doc.url}.\n\n\n———-\nThis is a system generated message. Please do not reply to this email.

 

location-mapping.n3 and location-mapping-to-empty.n3

These two files are used to find the exact path of the ontology (.OWL) files in the conf folder.

location-mapping.n3 is used in the load customizing and location-mapping-to-empty.n3 is used in the general start of the tenant application. In early MSP tenants the ontology files used to supply certain master data elements and load them up into database there mapping was kept in location-mapping.n3,

However, on system start as this uploaded data will be supplied by database it is needed that the files carrying the real data not be loaded into memory as well. This can happen as files have imports to base files. To separate this data ontology files with only import information were created and to find their path the location-mapping-to-empty.n3 file is used.

 

Note that there is no need to supply the data from ontology files anymore.

location-mapper.n3 file is a key mapper to map file’s unique identification (URI) with relative location of it.

Below is an example of clean location-mapper.n3 file which maps 2 different files.

Even though schema.owl file is the base file, the application-schema-ext.owl can be used to define additional ontology concepts to help customize the product based on the need of a customer. Legacy BDAs, SPARQLs and custom data points are usually defined inside application-schema-ext.owl.

Unless modularization becomes necessity, from 1811 onwards, it’s advised to limit the system to have just two files: schema.owl (Default import, which contains, product schema and necessary instances, comes by default) and application-schema-ext.owl (Custom extensions via SPARQLs, legacy DA/BRAs and instances).

The application-implementation.owl is an example of file having Instance/individual/Business Object data. This should be avoided, and all data should be maintained directly in the tenant system.

2.1.2 Ontology Files

Schema.owl

Schema.owl is the main file having all the entity definition and their relationship in the MSP. It contains all Classes (Business Types, BT), Data Attributes (Business Data Attribute, BDA) and Relation Attributes (Business Relation Attributes, BRA) defined in it. It also contains the meta attributes (Business Meta Attributes, BMA) that are used to define something about the BDA and BRA’s. Schema.owl also contains certain object (Individual, Business Object, BO), which are MSP defined objects.

For illustration purpose.

Account class (BT) in Schema.owl:


	<!-- http://www.inmindcloud.com/application/schema.owl#Account -->

		<owl:Class rdf:about="&as;Account">
			<rdfs:label rdf:datatype="&xsd;string">Account</rdfs:label>
		<rdfs:subClassOf rdf:resource="&as;Enterprise"/>
	</owl:Class>

Object Name attribute (BDA) in Schema.owl:


	<!-- http://www.inmindcloud.com/application/schema.owl#objectName -->

		<owl:DatatypeProperty rdf:about="&as;objectName">
			<rdf:type rdf:resource="&owl;FunctionalProperty"/>
			<rdfs:label rdf:datatype="&xsd;string">Name</rdfs:label>
			<sequenceID rdf:datatype="&xsd;int">1</sequenceID>
			<costingRelevant>true</costingRelevant>
			<rdfs:domain rdf:resource="&as;BusinessType"/> 
			<rdfs:subPropertyOf rdf:resource="&as;assertion"/>
			<rdfs:range rdf:resource="&xsd;string"/>
		</owl:DatatypeProperty>

Has Account Status relation (BRA) in Schema.owl:


	<!-- http://www.inmindcloud.com/application/schema.owl#hasAccountStatus -->

		<owl:ObjectProperty rdf:about="&as;hasAccountStatus"> 
			<rdfs:label rdf:datatype="&xsd;string">AccountStatus</rdfs:label>
			<attributeCardinality>1</attributeCardinality>
			<rdfs:domain rdf:resource="&as;Account"/>
			<rdfs:range rdf:resource="&as;AccountStatus"/>
			<rdfs:subPropertyOf rdf:resource="&as;has"/>
		</owl:ObjectProperty>

If an individual/business object is defined in schema.owl, it cannot be deleted from any tenant application. These are mostly control variables that MSP uses to enforce process with in the application or provided settings to control the behavior.

A setting object in schema.owl: (note that the value for such a BO comes from tenant database)


	<!-- http://www.inmindcloud.com/application/schema.owl#SettingAddNoteEmailEnabled -->

		<owl:NamedIndividual rdf:about="&as;SettingAddNoteEmailEnabled">
			<rdf:type rdf:resource="&as;SettingBoolean"/>
			<rdfs:label rdf:datatype="&xsd;string">SettingAddNoteEmailEnabled</rdfs:label>
			<objectName rdf:datatype="&xsd;string">Enables sending notification email to users when Notes are created</objectName>
		</owl:NamedIndividual>

2.2 Upgrading ontology

Addition to existing ontology/extension is available inside the system, however deletion is not permitted. It is available under Administration à Operation Settings as shown in below image.

2.2.1 Upgrading ontology

Clicking on Load Schema button upgrades ontology with added changes under schema.owl file.

2.2.2 Load Customization

Clicking on Load Customization button upgrades ontology with added changes under all the files mentioned under location-mapper in addition to schema.owl

3 User License Management

3.1 Introduction

License Management feature enables MSP admin to manage MSP license subscriptions and assignment of licenses to users. A license is required for a user to log into MSP. Admin user is required to have MANAGE LICENSE PERMISSION to execute license related operations.

3.2 License Subscription Management

Figure 1 - License Management
Figure 1 - License Management

“License Adjustments” section can be used to either subscribe or unsubscribe licenses. User can enter the number of licenses that needs to be adjusted and click on either “Subscribe” or “Unsubscribe”. In the case of unsubscribing, the resulting number of licenses should be greater than the sum of minimum allowed licenses (this is set at system provisioning) and the number of licenses assigned to users.

3.3 User License Management

From the subscribed licenses, users can be attached with licenses. MSP admin can also detach a user from a license at any time, once done, that license is available and can be attached to a different user. However, for a user to login to MSP, that user needs to be attached with a license. There are multiple ways to manage user licenses.

As illustrated in Figure 2 – User license management in license management view. License management view can be used to list all the users with their license status. From the pop-up user licenses can be managed for individual user using the toggle button in “Assign License” column. If needed to update the license status in bulk, user can select one or more users and click on “Toggle Subscription” button.

Figure 2 - User license management in license management view
Figure 2 - User license management in license management view

User list Figure 3 – User license management in user list can be used to manage license attachment to user individually. The same functionality is made available in user details view Figure 4 – User license management in user details view as well.

Figure 3 - User license management in user list
Figure 3 - User license management in user list
Figure 4 - User license management in user details view
Figure 4 - User license management in user details view

3.4 Report and Notifications to In Mind

A summary report on license subscription is generated and sent to In Mind finance department each month. Apart from that a notification is sent to the same upon subscribe / unsubscribe actions.

4 User Administration

Use administration module consists of Schema/System defined Permissions, Customer defined Roles and users.

4.1 Permissions

MSP supplies a set of permissions to fine control the access to various features of the application. These permissions are defined in schema.owl and can be uploaded into the system using operation setting: Load Schema objects.

List of available Permissions in the system can be accessed from: Administration-> Master Data Management-> Permission

Figure 5 - List of available permissions
Figure 5 - List of available permissions

Note: In case permission is missing in the system or not created.

User cannot create a new permission as this is controlled by the system. However, when a release comes to the system one can see that the permission is missing its Name like in screen shot below:

UI CUSTOMISING PERMISSION is available but not created in the system, go to administration-> operation setting -> load schema to reload the schema objects.

All permissions will be made available in the system upon execution of load schema.

4.2 Role

Roles are available under Administration-> Master Data Management -> Role. Under this, the roles can be created as the need be.

For example: Creating a new role for an admin user.

Create a role and named it ROLE_ADMIN (or a name of your choice).

Next assign this role permission: ADMIN PERMISSION

Alternatively, you can assign All Permissions which includes Admin Permissions.

The role also comes with concepts such as:

  • UI Profile – Which UI components are hidden/disabled for this role
  • Restriction Rules
  • Read Restriction Rules: Defines what quotes the role cannot see based on condition
  • Create Objects for Role: Deprecated now, this used to control the access where this role can create objects for other roles
  • Create Objects for Hierarchy: Deprecated now, this used to control the access where this role can create objects for another role Hierarchy
  • Access Data of Role: Deprecated now, this used to control the access where this role can access data from other roles.
  • Access Data of Hierarchy: Deprecated now, this used to control the access where this role can access data from another role hierarchy.
  • Editable Price Item: The price item types that this role can use in Quote pricing screen for creating new price item types.
  • Readable Price Item: The price item types that this role can see in Quote pricing. Note that all editable price items are automatically readable.
  • Workbook Template: The excel templates that are used in excel upload create of line items.
  • Report Template: are of types: Excel and PDF. These are role specific report templates that are used in Quote Proposal Generation.
  • Role Authority: Deprecated now. But still a value needs to be maintained. Earlier this was used to control access to data.

4.3 Users

User Management can be accessed from Administration->User Management. Users can be created and assign licenses.

Use details page.

 

Note that one user can be assigned with one Role only.

Most of the data points on a user are self-explanatory. However, a few need a mention:

  • User Name: Needs to be unique in the system
  • Language: Preferred user language, the system will try to create user session in this language first.
  • User Status: Active/Inactive/Locked, only Active users can log into the system
  • Auth Provider: Local/hcp: in case user uses MSP authentication or is driver by cloud platform based IDP authentication respectively.
  • External ID: The ID of user in CRM system.
  • ERP ID: The ID of the user in ERP system.
  • Assign License: User is assigned a license.

4.4 Sales Team

Sale Team is accessible by Administration -> User Management -> Sales Team.

Here one can create a sales team and assign users to it as team members.

The sales team can be used for following purposes:

1. To tag in notes, if done so all the members in the team will get email notification

2. To restrict the product shown to a user in product catalog while quoting.

The second can be done by assigning products to a sales team.

5 UI Profile

The two main features on UI Profile are:

i. allows MSP administrator to customize the localization value for the label use in application.

ii. allows MSP administrator to customize the user interface of the application for different group of users based on User Role.

Once the administration is given the UI Customizing permission and logs into MSP, he/she will able to see a “?” button located at the top right of the application.

Figure 6 - The "?" button located at top right of the application
Figure 6 - The "?" button located at top right of the application

5.1  UI Profile Creation

The two main features on UI Profile are:

i. allows MSP administrator to customize the localization value for the label use in application.

ii. allows MSP administrator to customize the user interface of the application for different group of users based on User Role.

Once the administration is given the UI Customizing permission and logs into MSP, he/she will able to see a “?” button located at the top right of the application.

5.1.1  UI Profile Creation

1. Clicks on the UI Profile button to open the UI Customization panel. The system displays the list of the label show on the page with it’s respective message key. The system will also highlight the label in orange which is currently focusing by the user.

2. Clicks on the localization label to update the new value. The systems will list the available language supported by the system.

3. Fills in the value for different language and clicks on the Save button to save the result. A re-login is required for the change to take effect.

* If the value is blank for a language, the system will fall back to get the value from the message.properties.

4. The system shows the new value for the label after the user re-login to the system.

5.2 UI Customization

Upon clicking on the button, a dialog will open showing all the available UI Profiles within the application, and these are the following actions available in order from left to right:

  • Create new UI Profile
  • Delete selected UI Profile(s)
  • Display UI Profiles in list view
  • Display UI Profiles in tree view

Refresh system cache (to be trigger whenever there are changes made to any UI Profile

Figure 7 - Actions available in order from left to right
Figure 7 - Actions available in order from left to right

5.2.1 UI Profile Creation

Upon clicking the “+” button, a dialog will be shown whereby the administrator can specify the name of the UI Profile to create

Figure 8 - UI Profile creation dialog
Figure 8 - UI Profile creation dialog

5.2.2 UI Profile(s) Deletion

Upon selecting 1 or multiple UI Profiles in the list view, the delete button will be enabled and the administrator can delete the selected UI Profile(s) from the application.

5.2.3 UI Profile(s) List View

Figure 9 - UI Profile(s) List View
Figure 9 - UI Profile(s) List View

5.2.4 UI Profiles(s) Tree View

Figure 10 - UI Profile(s) Tree View
Figure 10 - UI Profile(s) Tree View

5.2.5 Refresh Application Cache

Needs to be triggered whenever there are changes made to UI Profile.

5.3 Editing UI Profile

To edit a specific UI Profile, simply click onto the UI Profile that you wished to edit and in either the list / tree view

5.3.1 UI Customization

Lists all the available controls for hiding and/or disabling in the view that is being displayed currently. In addition, the administrator can click on the copy button to copy the localization key to be used in customer specific messages.properties file.

Figure 11 - UI Customization view for hiding and or disabling available controls
Figure 11 - UI Customization view for hiding and or disabling available controls

If the UI Profile in editing has control(s) that are hidden and/or disable which it inherits from the parent(s), then the control(s) will not be editable for the UI Profile. The administrator can hover the checkboxes to see which parent UI Profile restrict the control.

Figure 12 - Control disable for editing due to inheritance from parent UI Profile(s)
Figure 12 - Control disable for editing due to inheritance from parent UI Profile(s)

5.3.2 Overview

Administrator can update the basic information of the UI Profile.

Figure 13 - UI Profile basic information
Figure 13 - UI Profile basic information

5.3.3 Has UI Profile(s)

In this view, an administrator can assign the UI Profile in editing to inherit controls that are hidden and/or disabled from other UI Profile(s).

Figure 14 - Has UI Profile(s) view

5.3.4 Uses Sales Document Status

In this view, an administrator can indicate if the UI Profile in editing will be applicable to certain Quote’s Document Status, such as Open, Approved, Completed etc.

Figure 15 - Uses Sales Document Status view
Figure 15 - Uses Sales Document Status view

5.3.5 Uses Sales Phase

In this view, an administrator can indicate if the UI Profile in editing will be applicable to certain Opportunity’s Sales Phase, such as Identify Opportunity, Quotation etc.

Figure 16 - Uses Sales Phase view
Figure 16 - Uses Sales Phase view

5.3.6 Localization

In this view, an administrator can provide a different label and description for the UI Profile to cater for different language. If nothing is specified, MSP will fallback the label and description to the default which is English.

6 DA Profile

6.1 Introduction

DAProfile helps user to hide DA/DA-value(s) based on specific conditions. The conditions are specified in IMCExpression.

6.2 Prerequisite

Understanding of Schema, IMCExpression and LookupTable.

6.3 Steps to configure and use DAProfile

Here are the steps to make use of DAProfile.

6.3.1 Step 1: Create Lookup Table

User needs to create a LookupTable to specify dependent factors, DA name as well as DA value inside the table. User can name the table as the need be.

As you can see, in image, ‘Fetch Record’ data types are useful to specify dependent factors (i.e. SALES_OFFICE and ROLE_NAME in this example), whereas DA_NAME and DA_VALUE columns are mandatory columns for the table, which can be described as a ‘Data Record – String’. User can choose the column names as needed.

New DA Value - Fetch Record

Once the table is created, it needs to be activated and create records to specify which DA/DAValue should be hidden. Creation of records can be done either by UI or by Excel import.

6.3.2 Step 2: Link table to DAProfileInstance

Next step should be to link created LookupTable to DAProfile instance. This instance is there by default under Administration è DAProfile

Under this DAProfile instance 3 things need to be selected: DAProfile table, and the columns: DAName and DAValue. As shown in above image.

6.3.3 UI Profile(s) List View

Once above steps are followed, user can simply test it by going under SI è Configuration and check expected outcome. In above image DDA1 and DSA1 è DSA_Value1 is hidden.

6.3.4 UI Profiles(s) Tree View

After opening a SalesItem, the audit logs can be found under tab Administration è Content Management. (To see audit logs, Server should be running under DEBUG mode with log for DAProfile enabled)

Successful triggers on DA/DAValue(s) will be shown in audit table.

7 Locking Mechanism

7.1 Introduction

Locking mechanism helps restricting multiple users updating same object simultaneously. For example, for Quote, if one user has applied certain changes, another won’t be allowed to update on it.

This lock gets released when the user having access, saves or discards the changes. Subsequent notifications are pushed to the failed users during this.

7.2 Types of locks and configuration

Lock can be configured simply by setting com.imc.context.LockRegistry value inside application properties.

com.imc.context.LockRegistryDescription
MEMORY_BASEDApplies memory level locking.
DATABASE_BASEDApplies DB layer locking, useful on multiple VM/Computing units.
NULLLock feature disabled.

Even though Memory based lock is slightly performance effective, Database based lock provides completeness by supporting multiple VM/Computing units. By default, Database based lock is assigned if not configured anything.

8 Audit Service

8.1 Introduction

The Audit Service records the events that occurred in the execution of a transaction in MSP. It provides basic information to backtrack through the entire trail of events to its origin which includes user activities, access to data, and administrator activities. The information committed to database will be recorded and saved into the audit table-T_SYS_AUDIT.

8.2 Types of locks and configuration

An audit records consists of 14 columns. The table below describes the definition for each of the column.

Table 1 Definition of Audit Table – T_SYS_AUDIT

NoColumn NameData TypeDescription
1.IDBIGINTThe auto increment ID in audit table.
2.GRAPH_IDNVARCHAR(MAX)The URI of the primary data (ie: Account, Quote, Opportunity) in the Tuples table.
3.GRAPH_TYPENVARCHAR(MAX)The subject type of the primary data.
4.SUBJECTNVARCHAR(MAX)The URI of the primary or dependent (SalesItem, ItemHeaderPriceItem) data in the Tuples table.
5.SUBJECT_TYPENVARCHAR(MAX)The subject type of the primary or dependent data.
6.PREDICATENVARCHAR(MAX)The term used to denote relationships between the subject and the object.
7.OLD_VALUENVARCHAR(MAX)The old “target” or “value” of the triple.
8.NEW_VALUENVARCHAR(MAX)The new “target” or “value” of the triple.
9.IS_LITERALINTEGERAn indicator to indicate whether the triple is a relation or literal value.
10.SESSION_IDNVARCHAR(MAX)The user login session Id which is generated by the system.
11.ACTION_TYPENVARCHAR(MAX)The action of the event (CREATE, UPDATE, DELETE)
12.USERNAMENVARCHAR(MAX)The username of the user which created or modified the data in MSP.
13.LAST_MODIFIEDTIMESTAMPThe modified date of the audit record.
14.STATUSINTEGERA soft delete indicator (0 = Active, 1 = Inactive) in lookup table.

8.2.1 Types of locks and configuration

The information below are excluded by Audit Service:

  • Transaction data of Lookup Table.
  • Transaction data of CMIS.

8.3 Types of locks and configuration

The section below explains about the settings to enable / disable, pause / resume audit service.

8.3.1 Enable/Disable Audit Service

By default, Audit Service is always enabled for MSP. To enable / disable the audit service permanently, MSP administrator can add the property below into the application.properties and restart the application.

com.imc.iss.audit.enabled= true

where value true = enable audit service, false = disable audit service

8.3.2 Pause / Resume Audit Service

The audit service can be paused/resumed at application run time by the SAP Cloud Platform Cockpit Administrator. Please follows the steps below to pause/resume the audit service when required.

1. Login to SAP Cloud Platform Cockpit and go to the Overview of the Java Application.

2. Clicks on the JMX Console, search with ‘Audit’ keyword and looks for Audit Monitor. Clicks on the Operations, two operations (startAudit, stopAudit) are available for Audit Monitor.

3. Clicks on the Execute button for stopAudit to pause the audit service, whereas clicks on the Execute button for startAudit will resume the audit service. Once the operation is executed, the result will show on the Operation Results.

8.3.3 Logger

The below loggers are available for Audit.

  1. imc.audit.AuditJob – Showing the error/debug log when audit job inserting audit data into database.
  2. imc.audit.AuditListener – Showing the error/debug log when AuditListener processing the audit data before sending the audit data to audit queue.
Configure Logger

8.4 Audit Query Service

The audit query service provides a graphical user interface for system administrator to query, navigate and narrow down the MSP audit log. Administrator can access the audit table via Lookup -> Audit.

Figure 17 - Audit Table in MSP
Figure 17 - Audit Table in MSP

The figure below shows the audit result. Please follow the sequence number in the diagram for the explanation.

Figure 18 - Audit Result
Figure 18 - Audit Result

1. By default, the system displays the latest audit records which are always sorted by column LAST_MODIFIED DESC, SUBJECT_TYPE ASC and PREDICATE ASC.

Each row represents one audit record. Given the example below, the user with username admin updated the linksAddress of the Subject which is having subject type of PartnerFunctionRecord in a Quote. Since linksAddress is a BRA, the value is represented with hyperlink which allows the administrator to clicks on it in order to view it’s detail.

2. The system shows the value in the column OLD_VALUE and NEW_VALUE with hyperlink if the triple is relation whereas literal value is shown with plain text. If the hyperlink is clicked, the system will open a new audit result tab which shows all the details of the subject.

*The new audit result tab is blank if there is no audit record for the subject since the audit service is introduced after the creation of the subject.

Figure 19 - New Audit Result Tab
Figure 19 - New Audit Result Tab

3. The Facet Filter helps the administrator to narrow down the audit result by applying multiple filters.The available faceted filters to filter / navigate the audit result are:

1. Graph Type – Filtering audit records by primary data type in MSP.

2. Actions – Filtering audit records by the event type (Create, Update, Delete)

3. Subject Types – Filtering audit records by primary / dependent data type in MSP.

4. Predicate – Filtering audit records by predicate.

5. Subject Name – Filtering Subject by the object name of a Subject

6. Username – Filtering audit records by user.

7. Date – Filtering audit records by the LAST_MODIFIED column. The system can retrieves only up to the latest 3 months of audit records.

8. Search for – Searching into the column OLD_VALUE and NEW_VALUE which contains the query string.

The values of the Facet Filter are derived from the audit result set. It helps the administrator to understand the available contexts and what are the data available for filtering / narrow down the audit result. The capability applying multiple facet filters at the same time can quickly help the user to zoom down to the information he/she wanted to read. Once a filter is applied, for example the Account in the Subject Type is selected, the audit result remains only audit records with subject type Account.

Figure 20 - Facet Filter
Figure 20 - Facet Filter

4. The pagination allows the user to navigate the audit result by next page, previous page, first page and last page. Each pagination fetches 50 audit records.