Global Track and Trace Plugin for SAP Web IDE · PDF fileThe MM app is an SAP Web IDE plugin,...

A Guide for Administrators PUBLIC

SAP Global Track and TraceDocument Version: Cloud 2018.04a – 2018-04-19

Metadata Modeling AppGlobal Track and Trace Plugin for SAP Web IDE

Content

1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1 About this App. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 About this Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

1.3 Target Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Working with the MM App. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1 Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2.2 Create a GTT Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Configure the Project Settings (Optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Design-time Modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Model a Tracked Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Set up Services and UI Annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Deploy a GTT Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6 Notes on Changing a Deployed Metadata Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Structure of Track and Trace Metadata. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1 Basic Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Representation as Entity Relationship Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

3.4 GTT Metadata Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Event-to-Action Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1 Feature Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2 Enabling the Event-to-Action Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

4.3 Defining Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Modeling Language Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.1 Introduction to CDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Architecture and Design Principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

CDS Definition Language (CDL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Language Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

5.2 GTT Metadata Model with CDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Overall Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Core Model Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

UI Annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Delivery Application Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

2 P U B L I CMetadata Modeling App

Content

Shipment Application Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Metadata Modeling AppContent P U B L I C 3

1 Introduction

1.1 About this App

SAP Global Track and Trace uses the Metadata Modeling app (MM app) as a modeling tool and it is responsible for managing user-defined metadata of models.

NoteThe MM app is an SAP Web IDE plugin, also known as the Global Track and Trace plugin for SAP Web IDE.

Users can use the MM app to create, modify, and delete their metadata models then save them either in the temporary workspace or in GIT repository they define. After finishing the metadata definition, users can deploy and activate the metadata model in the runtime repository. This is a microservice on the target runtime environment and provides data access APIs to other components or microservices.

Metadata models include tracked processes and events. The metadata models are in a specific GTT project called a namespace. One namespace belongs to one specific user and may have multiple versions. Users currently define metadata models in the format of CDS (CDS Definition Language).

1.2 About this Document

This document guides you through how to use the MM app to do Track and Trace modeling involving the following tasks:

1. Create a GTT project.2. Configure the project settings (optional).3. Work in the MM app to model tracked process.4. Deploy the GTT project.

Before you start working through this document, ensure that you have downloaded the most recent version of this document that is available from:

https://help.sap.com/viewer/p/SAP_GLOBAL_TRACK_AND_TRACE


Introduction

https://help.sap.com/viewer/p/SAP_GLOBAL_TRACK_AND_TRACE

1.3 Target Audience

Table 1:

Role Activity

Customer Modeling Expert Create, maintain, deploy, and activate GTT metadata models.

1.4 Features

This section gives you an overview of the features and functions of the Metadata Modeling app.

● Creating a GTT Project with a WizardA wizard guides you through the process of creating a GTT project.

● Configuring the Project SettingsYou can configure the GTT project in the project settings panel.

● Modeling Tracked ProcessIn a GTT project, you can model tracked process in CDS format.

● Setting Up Services and UI AnnotationsWorking in a GTT project, you can set up services and UI annotations for tracking events and processes.

● Deploying a GTT ProjectAfter modeling, you can deploy the GTT project to the runtime repository.

Metadata Modeling AppIntroduction P U B L I C 5

2 Working with the MM App

The MM app provides you with an easy-to-use development interface to model tracked processes and events.

2.1 Prerequisites

Ensure that you have selected the Track and Trace plugin in the Features page (this is a one-time activity).

1. Log in to the SAP Web IDE for Full-Stack Development application.2. In the Tools menu, choose Preferences.3. Select Features in the left pane.4. In the Features view that displays on the right pane, switch on Global Track and Trace and choose Save.5. Reload the SAP Web IDE Full-Stack application by refreshing the browser.

2.2 Create a GTT Project

Context

You can create a GTT project using either the default standard mode or the simple mode.

● Standard mode defines GTT metadata model with complete model and UI layout information, which can handle complex user scenarios.

● Simple mode simplifies the modeling by defining your metadata model with model information and basic UI layout information in only one model file. This mode supports GTT projects that only contain one tracked process.

A wizard guides you through the process of creating a GTT project.

Procedure

1. Choose File New Project from Template . The Template Selection page appears.2. In the Category list, choose SAP Global Track and Trace and then choose Next.3. Type a Project Name for your GTT project.


Working with the MM App

4. Choose Next. The Project Customization page appears.5. Choose Standard or Simple mode.6. Type Namespace and Version, choose Template and type Description. Then choose Next or Finish.

NoteHere a template means a sample implementation pre-defined in a group of sample files. You can also choose None if you want to model a tracked process without using a template. In that case, you can also specify a dependency metadata model in the Dependency box. Then your new metadata model can use the entities and attributes defined in the dependency metadata model.

7. If you choose Next in the previous step, choose Finish.

Results

A GTT project is created. Below shows an example of a standard mode project with a delivery template.

2.3 Configure the Project Settings (Optional)

Context

GTT project settings (information gathered from the project customization step when creating a new GTT project) can be changed using project settings.

Metadata Modeling AppWorking with the MM App P U B L I C 7

NoteGTT project settings are held in the project.json file. But to avoid unexpected results, do not manually modify the settings in this file.

Procedure

1. Choose Development ( ) in the left pane and navigate to the Workspace folder.2. Select a folder for your GTT project.

3. In the context menu of the folder, choose Project Settings . The Project Settings dialog appears.4. Select SAP Global Track and Trace and modify the SAP Global Track and Trace project settings information.

5. Choose Save .

2.4 Design-time Modeling

Metadata models include tracked processes and events. You can define models in the format of CDS.

2.4.1 Model a Tracked Process

Working in a GTT project of simple or standard mode, you can model a tracked process in CDS format.



Procedure

1. Choose Development ( ) in the left pane and navigate to the Workspace folder.

2. Under Workspace your project model , do one of the following:○ If your GTT project is created with the Delivery template, open the DeliveryModel.cds file and modify the

template.○ If your GTT project is created with the Shipment template, open the ShipmentModel.cds file and modify

the template.○ If your GTT project is created without a template, open the <project_name>Model.cds file and model the

tracked process in the editor in CDS format.

NoteIt is recommended that you do not change the file name of DeliveryModel.cds, ShipmentModel.cds, or <project_name>Model.cds. If you do want to change the file name, you can only change the "Delivery", "Shipment", or "<project_name>" part, not the "Model.cds" part, otherwise the deployment of the metadata model will fail.

3. In the File menu, choose Save .

Related Information

Modeling Language Guide [page 24]

2.4.2 Set up Services and UI Annotations

Working in a standard mode GTT project, you can set up services and UI annotations for tracking events and processes.

NoteThe setup is not available for a simple mode GTT project.

Procedure

1. Choose Development ( ) in the left pane and navigate to the Workspace folder.2. To set up services, for example, configure the fields to be exposed for display in the GTT app, do the following:

1. Under Workspace your project service , open the DeliveryService.cds file if your GTT project is created with the Delivery template, the ShipmentService.cds file if your GTT project is created with the


Shipment template, or the <project_name>Service.cds file if your GTT project is created without a template.

2. Modify the file in the editor in CDS format.

NoteIt is recommended that you do not change the file name of DeliveryService.cds, ShipmentService.cds, or <project_name>Service.cds. If you do want to change the file name, you can only change the "Delivery", "Shipment", or "<project_name>" part, not the "Service.cds" part, otherwise the deployment of the metadata model will fail.

3. In the File menu, choose Save .3. To set up UI annotations, do the following:

1. Under Workspace your project service , open the DeliveryUI.cds file if your GTT project is created with the Delivery template, the ShipmentUI.cds file if your GTT project is created with the Shipment template, or the <project_name>UI.cds file if your GTT project is created without a template.

2. Modify the file in the editor in CDS format.

NoteIt is recommended that you do not change the file name of DeliveryUI.cds, ShipmentUI.cds, or <project_name>UI.cds. If you do want to change the file name, you can only change the "Delivery", "Shipment", or "<project_name>" part, not the "UI.cds" part, otherwise the deployment of the metadata model will fail.

3. In the File menu, choose Save .

Related Information

Modeling Language Guide [page 24]

2.5 Deploy a GTT Project

Context

After modeling, you can deploy the GTT project to the runtime repository.



Procedure

1. Choose Development ( ) in the left pane and navigate to the Workspace folder.2. Select a folder for your GTT project.

3. In the context menu of the folder, choose Deploy Deploy Track and Trace Project Activate .

Note

If you want to compile your metadata model only and activate it at a later time, choose Deploy Deploy Track and Trace Project Compile .

You can also preview a compiled or activated metadata model by choosing Deploy Deploy Track and Trace Project Preview . The preview shows mock data only, not the real data.

2.6 Notes on Changing a Deployed Metadata Model

After a metadata model is deployed to the runtime repository, you can make limited changes to the metadata model and deploy it again.

The following lists the changes that are allowed and forbidden for a deployed metadata model.

Allowed Changes

The following changes are allowed for a deployed metadata model. Making these changes do not require the creation of a new version of the namespace. Allowed changes do not lead to any data conversion.

● Adding fieldsAdding fields to an entity is allowed if there is a canonic default value for all instances not being created with this field. For integer such a value would be 0, for associations NULL, and for strings the empty string.

● Increasing length and precisionIncreasing the length of a string and the precision of a decimal is allowed because the original type is not changed.

● Changing UI annotationsUI changes are allowed because UI is rendered during the runtime following the Fiori Elements approach.

● Changing enum valuesSimilar to UI annotations, enum defines a set of possible values with symbolic names. Changing enum values does not lead to any data conversion.


Forbidden Changes

All changes that are not included in the Allowed Changes list above are forbidden for a deployed metadata model. Such changes may lead to data loss or inconsistencies.

Some examples of forbidden changes are as follows.

● Deleting entities or views/projectionsOnce an entity or view is being released, it must not be deleted. The deletion will lead to inconsistent models and data loss on consumer side.

● Deleting fields from an entityThis leads to data loss and must be prevented.

● Demoting a primary key field to functional fieldThis changes the structure of the object and access patterns, storages and uniqueness constraints.

● Changing field type and length with value narrowingChanging the type or length of a field may narrow the allowed values in the field and lead to data loss or inconsistencies. For example, if you change a field type from string to integer, the previously allowed value “ABC” will become invalid. For associations, the associated type must not be changed.



3 Structure of Track and Trace Metadata

The central purpose of any track and trace application is to track processes that are influenced by business events. All tracked processes and business events have a common core behavior and share a common set of basic attributes.

Therefore, the overall Track and Trace solution consists of a generic track and trace core engine and applications leveraging the core engine:

● The core engine provides generic functionality to track processes, to handle business events and the core engine provides the modeling environment described in this document.

● Track and Trace applications enrich the generic functionality by adding domain specific semantics in terms of data, behavior, and user experience using SAP Web IDE.

Both the core engine’s data model and the application’s data model are described by metadata as a classical entity relationship model with various enhancements like annotations and extension concepts.

3.1 Basic Definitions

Before we describe the structure of the Track and Trace Metadata, let us briefly describe the central objects and terms any track and trace application deals with:

● Tracked ProcessA tracked process comprises○ Involved parties acting in or being affected by the process;○ Multiple tracked objects (please note, for first applications tracked objects are not in scope and hence

there are no links to tracked objects);○ A set of planned events that are expected to happen within the tracked process. The planned events are

also named as milestones.

Note“Milestones” is the term used in SAP ERP applications like SAP Event Management.

○ A set of events that actually happened against the process. This could be a realization of a planned event or also an unplanned event

● EventsEvents can be planned events or unplanned events that might occur against a process. When an event happens, we have an actual event that needs to be matched against a planned event of that process or will get an unplanned event in case no suitable planned event can be identified. Otherwise if no suitable planned event can be identified it becomes an unplanned event.○ Planned Event

○ Has a fixed semantic.

Metadata Modeling AppStructure of Track and Trace Metadata P U B L I C 13

○ Has a planned date and time (with time zone) + tolerance window, planned location, other planned data.Examples:○ goods issued (planned date 2016-07-06, planned location gate 1)○ goods received (planned date 2016-07-07, planned location packstation 801)

● Unplanned Event○ Has a fixed semantic as well○ Is not planned, but can be foreseen that it occurs with a certain likelihood, but cannot be planned thus has

not plan data○ E.g. delay in delivery, damage of goods○ Or is a piece of information at an arbitrary point in time, e.g. current position and temperature of a

container● Actual Event

○ The event that actually has happened○ Will either be matched against a planned event of a process and complements plan data with actual data

or will become an unplanned event of the process○ Will trigger changes of attributes of a tracked object / tracked process○ Updated data depends on message payload or specific unplanned event types for specific updates

● Event MessageThe event message is the transmitter that reports the occurrence of an actual event. The event message contains the actual data of the event and the information to which tracked processes the event is related to.The event message may trigger the update and creation of tracked processes.

3.2 Example

To illustrate the structure of the metadata and the modeling language, we will use a delivery process, outbound delivery, as an example.

Example: Delivery Process

A delivery process within a business network comprises at least three involved parties: A supplier as sender, a carrier and a customer as receiver of the delivery: The customer orders a good from the supplier. The supplier starts a delivery process and hands-over the good to the carrier. The carrier delivers the good to the customer and the customer confirms the complete delivery.

Within this example we see one process and at least three events:

● Picking completed● Goods issued● Proof of delivery

These events describe the planned process flow and therefore are called planned events. But we can also think of unplanned events that may happen and foresee them in the delivery process tracking. For example, the truck of the carrier has an accident which leads to loss of the goods. The supplier has to react to that and send the good again as the customer requires it. Financial compensation for damaged good and delays is another process.


Structure of Track and Trace Metadata

3.3 Representation as Entity Relationship Model

The core engine knows these central terms and objects from a generic perspective. In terms of an entity relationship model the core engine provides entities for generic abstract tracked processes and generic events. These generic entities contain data that is common to all applications and which is used within the core engine. The core engine does not provide any definition of event messages, as the message is only the carrier for the event itself, hence the message content is derived from the event that is reported.

Generic Tracked Process

The generic tracked process consists of

● a universal unique ID that is issued internally as a technical key● a description of the process, which is some free text to describe and identify the tracked process● a process type that technically distinguishes the different tracked processes defined by applications● a set of tracking Ids that externally identify a tracked process● a set of events that are planned with the tracked process and/or have already occurred combined with a set of

unplanned events

Generic Event

The generic event contains

● a universal unique ID that is issued internally as a technical key● an event code that allows you to distinguish between different event types and data assigned to these event

types● a status of an event like “delayed” or “open”● a location where the event has happened● in case of a planned event, plan data by when the event is expected to happen or expected to be reported● actual data when the event has actually happened and when the event actually has been reported

The core engine offers generic functionality like monitoring of overdue events or alerting in case of unplanned events leveraging these generic set of attributes.

Application Enhancements

Track and trace applications enhance the generic parts with their domain specifics. This could be any simple attributes, structures or even additional entities in the sense of ERM (Entity-Relationship Modeling). This enhancement can be considered as an “is-a” relationship between the application specific process / event and the generic process / event.

Example:


In our delivery example, a delivery process is-a tracked process, whereas the tracked process can-be a delivery (but also something else that is defined based on that concept).

Customer Enhancements

In many cases, pre-configured applications delivered by SAP are not sufficient to cover all requirements from customers. Hence customers need also a possibility to enhance delivered applications. Luckily, the entity relationship model allows multiple levels of extension.

Entity Relationship Model

In UML notification, we can provide the structure of the entity relationship model as shown in the following figure.

3.4 GTT Metadata Model

As described above, tracked processes and events are entities in terms of an ERM. Entities are described by annotations and properties: Properties model the content of events and tracked processes whereas annotations describe use case specific static behavior like UI texts. Both are either scalar values, complex structures or (deep) table types. The latter would be a separate weak entity in a classical ERM. The GTT metadata model now describes how tracked processes and events are being modeled so that the core engine and applications can leverage the definitions.

The following figure shows that metadata model and the relation to the ERM Model above.


Structure of Track and Trace Metadata

When you start a new GTT project within SAP Web IDE, the generic definition for tracked processes and events is immediately available and can be enhanced with application specifics. On the other side, the generic part must not be changed, otherwise the core engine would not work reliably any more. To avoid unintentional modifications, the core engine definition is not editable for users so it cannot be changed accidentally. The application specific definition happens in new files that import the core engine definition.


4 Event-to-Action Engine

The Event-to-Action engine allows you to define rules to automatically trigger actions if certain events are processed for a tracked process instance.

The admin user of the GTT solution owner can define and activate rules for their GTT models to enable event-to-action for the corresponding tracked processes. Once the rules are activated, whenever an actual event occurs that matches the conditions defined in the rule, that rule is triggered and its action is put into effect.

The Event-to-Action engine improves the flexibility and efficiency of the SAP Global Track and Trace solution.

4.1 Feature Scope

In the current release, the feature scope of the Event-to-Action engine is as follows.

● Four types of rule services, which correspond to four action types, can be deployed to a GTT model:

Table 2:

Rule Service Description

ActionTPupdater Updates the status properties or the header properties of a tracked process instance.

ActionFLPnotification Sends SAP Fiori Launchpad notifications to specific users.

ActionCPIforwarding Forwards the tuple consisting of tracked process type and event to SAP Cloud Platform Integration.

ActionPersonalDataRetentionDateUpdate Configures the residence period and retention period of users' personal data.

● Only the admin user of the GTT solution owner can define and activate rules to enable the Event-to-Action engine.

● You can only define and activate rules in the GMM app. Rules defined or deployed in the SAP Cloud Platform Business Rules service are not supported.

● You can only define rules of type Decision Table. Rules of type Text Rule are not supported.● The Event-to-Action engine supports as input a tuple of a tracked process instance and an actual event.● The processing of an actual event for a tracked process instance triggers the rule execution.● It is assumed that when an actual event is received, its corresponding tracked process is already available and

is thus ready for correlation.


Event-to-Action Engine

4.2 Enabling the Event-to-Action Engine

The use of the Event-to-Action engine involves the following components.

Table 3:

Component Tasks to Accomplish Design Time/Run Time

MM app Deploy a GTT model of a tracked process.

Design time

GMM app Define and activate rules for predefined rule services.

Design time and run time

GTT Event-to-Action engine Execute rules when processing business data.

Run time

GTT app View the actions triggered by the Event-to-Action engine.

Run time

To enable the Event-to-Action engine for a GTT model, the admin user of a GTT solution owner must perform the following steps.

Step 1: Deploy a GTT Model in the MM App

In the MM app, create and deploy a GTT project. For a detailed procedure, see the Working with the MM App section in this document.

When a GTT project is deployed, the tracked process entity and event entities in the GTT model are automatically mapped to business rule data objects, and the elements of the entities are mapped to data object attributes. In the following step, you will use these data objects and attributes to define your rules.

NoteYou can only use the top-level elements of an entity to create rules. Associations to other entities cannot be used in rule definition.

Step 2: Define and Activate Rules in the GMM App

In the GMM app, locate your GTT model, and define rules for the model. For a detailed procedure, see the Create a Rule section in the GMM app document.

After the rules are created and saved, choose Activate to put them into effect.

Metadata Modeling AppEvent-to-Action Engine P U B L I C 19

NoteRules used for GTT models must be created and activated in the GMM app. Rules defined or deployed in the SAP Cloud Platform Business Rules service are not supported.

Step 3: View Triggered Actions in the GTT App

Now the Event-to-Action engine has been configured and enabled. When you track and trace business processes and events with the GTT app, if an actual event is processed for a tracked process instance, the corresponding rules are evaluated. For each condition that evaluates to true, the related action defined in the rule is automatically triggered.

4.3 Defining Rules

As the admin user of a GTT solution owner, you can define rules for use in the Event-to-Action Engine.

Data Objects for Defining Rules

When a GTT model is deployed in the MM app, the following data objects are automatically generated based on the content of your model. You can use them to define your rules in the GMM app.

● The tracked process itself is available as a data object, with its header level properties as the data object attributes.

● Each planned and unplanned event defined in the GTT model is available as a data object, with its header level properties as the data object attributes.

Rule Services

The GMM app provides the following rule services with predefined format of result and result attributes. You can define rules for any of these four rule services, which correspond to four action types supported by the Event-to-Action engine.

● ActionTPupdater● ActionFLPnotification● ActionCPIforwarding● ActionPersonalDataRetentionDateUpdate



Rule Definitions and Decision Table Settings

Rules are defined in the GMM app. You can only define rules of type Decision Table. Rules of type Text Rule are not supported. The rule definitions and decision table settings are shown below.

NoteRules used for GTT models must be created and activated in the GMM app. SAP Global Track and Trace does not support rules defined in the SAP Cloud Platform Business Rules service.

ActionTPupdaterThis type of rules is used to update the status of a property of a tracked process instance upon certain events. You need to specify the following for the rule:

● Condition Expression: the condition under which a property status will be updated.● Result Attributes

○ attribute1: the property whose value will be updated once the specified condition is met.○ value1: the new status that the property will be updated to.○ You can also specify attribute2/attribute3 and value2/value3, if more than one properties will change

values.

Example

To define a rule that expresses the following logic:

● If an event of type DelayedEvent is processed for an instance of the delivery tracked process and the "NewDeliveryDate" in the event message is later than the "DeliveryDate" in the delivery tracked process, then update the delivery status of the delivery tracked process to value "Critically Delayed".

● If no "NewDeliveryDate" is sent with the event message, or if it is not later than the "DeliveryDate" in the delivery, do nothing.

The decision table can look like the following:

● Condition Expression: NewDeliveryDate of the DelayedEvent of a DeliveryProess is later than deliveryDate of the DeliveryProcess

● Result Attributes○ attribute1: 'deliveryStatus'○ value1: '03'

ActionFLPnotificationThis type of rules is used to send SAP Fiori Launchpad notifications to specific users upon certain events. You need to specify the following for the rule.

● Condition Expression: the condition under which a notification will be sent.● Result Attributes

○ priority: priority of the notification in Fiori Launchpad. Available values are 'High', 'Medium', and 'Low' (the first letter must be capitalized).

○ recipients: email address of the notification recipient. If there are multiple recipients, separate the email addresses with semicolons.

○ message: the content of the message that the recipient(s) will receive.

Example



● If the delivery status of a delivery tracked process is updated to value "Critically Delayed", then trigger a notification in SAP Fiori Launchpad. This should be set up for all the responsible users (solution participants).

● Otherwise, do nothing.


● Condition Expression: NewDeliveryDate of the DelayedEvent of a DeliveryProess is later than deliveryDate of the DeliveryProcess

● Result Attributes○ priority: 'High'○ recipients: '<mail_address_1>;<mail_address_2>'○ message: 'Critically delayed event is received'

ActionCPIforwardingThis type of rules is used to forward the tuple consisting of tracked process type and event to SAP Cloud Platform Integration. It requires an integration flow across different systems. Most configuration is done in relevant systems, such as the customer's SAP ERP system, SAP Cloud Connector, and SAP Cloud Platform Integration. Besides that, you also need to specify the following for the rule.

● Condition Expression: the condition under which the configured data forwarding will happen.● Result Attributes

○ CPIEndpoint: the URL of the SAP Cloud Platform Integration endpoint.

Example


● Condition Expression: eventCode of the DepartureEvent contains 'DEPARTURE'● Result Attributes

○ CPIEndpoint: https://<your CPI server IP address>/http/ERP/INBOUND_DLV

ActionPersonalDataRetentionDateUpdateThis type of rules is used to configure the residence period and retention period of users' personal data. You need to specify the following for the rule:

● Condition Expression: the condition under which the residence and retention periods are configured.● Result Attributes

○ residencePeriodTimeUnit: time unit of the residence period. Available values are ‘M’ for months, ‘D’ for days, and 'Y' for years.

○ residencePeriod: the time period starting from the end-of-business date after which the planner’s personal data will be invisible to users except the users with special authorization.

○ retentionPeriod: the time period starting from the end-of-business date after which the planner’s personal data will be deleted from the relevant tracked process.

○ retentionPeriodTimeUnit: time unit of the retention period. Available values are ‘M’ for months, ‘D’ for days, and 'Y' for years.

○ endOfBusinessDate: the time when the relevant tracked process is marked as end of business.

Example

Suppose there is a tracked process that contains a planner’s personal data, including email address, name, mobile phone, etc.



NoteIn the tracked process metadata model, the properties that represent the planner’s personal data must be marked with DPP annotations.


● Sets the residence period to 12 months, starting from the process reaches end of business. After the residence period, the planner’s personal data will be blocked to users except the users with special authorization.

● Sets the retention period to 24 months, starting from the process reaches end of business. The retention period is a combination of the residence period and the blocking period. After the retention period, the planner’s personal data will be deleted from the tracked process.


● Condition Expression: eventCode of the ProofOfDeliveryEvent of a DeliveryProcess is equal to ‘POD’

● Result Attributes○ residencePeriodTimeUnit: 'M'○ residencePeriod: 12○ retentionPeriod: 24○ retentionPeriodTimeUnit: 'M'○ endOfBusinessDate: actualBusinessTimestampUTC


5 Modeling Language Guide

The language of choice for GTT metadata model now is the CDS Definition Language (CDL) of the Core Data Services (CDS) concept. CDS follows the principles of entity relationship models with annotations and can easily be interpreted by compilers and thus transferred in other formats following ERM principles like the metadata document describing OData services.

Before we describe the usage of CDS for Track and Trace solutions we briefly give a general overview of CDS and describe those portions of CDS that are currently used for Track and Trace solutions.

5.1 Introduction to CDS

Data models represented in CDS Definition Language (CDS) are written in a more or less human readable language, compiled and transferred into other machine readable formats like JSON or XML. This makes CDS an optimal format to share and interpret models with minimal footprint and dependencies, independent of source or target environments.

5.1.1 Architecture and Design Principles

The following sections outline the key building blocks of a conceptual reference architecture for CDS implementations as well as the key design principles of CDS.

5.1.1.1 Key Building Blocks

The following figure shows the key building blocks for CDS implementations.


Modeling Language Guide

Compiler

The compiler accepts metadata model definitions in source format (i.e. CDL) and processes them in these (logical) steps:

Table 4:

Step Description You can now...

Compile The compiler frontend compiles sources into an internal format. This internal format can be represented in CDM.

persist them, share/import them to other systems, or process them in 'diy' mode.

Import The definitions from compiled models are written to the catalog, contained annotations to the annotation service.

browse and introspect definitions, resolve annotations, add extensions, etc.

Activate The compiler backend generates runtime artifacts for the given definitions, i.e. SQL tables and views.

run queries to read/write data using the usual CRUD operations.

Implementations are not required to offer these steps individually. If they do, this allows you to deal with models transiently, for example, to dynamically create local temporary models at runtime.

Catalog

The catalog stores compiled models, i.e. the defined types and entities as well as extensions thereof. Note that extensions are not applied by the catalog. They are just stored as is.

Introspection APIs – Each CDS implementation is expected to provide a REST-based Introspection API that allows you to browse models, filtered by certain metadata and return complete model excerpts in CDM (Common Data Model) format. In addition, implementations may offer other forms to introspect models, for example, through the like of SQL catalog views.

Model Import APIs – CDS implementations should provide a REST-based API to import models in CDM format. This allows you to easily share models between CDS implementations in different stacks within heterogeneous landscapes. As opposed to the source/compiler-based way to add models, only essential checks are required.

Runtime

The runtime executes queries based on activated models, i.e. generated runtime artifacts. In case of the standard implementations, these are SQL tables and views. Upon generation, potential extensions are applied to the base definitions' runtime artifacts.

Given the standard SQL persistence, CDS needs only a minimal runtime on top of SQL, if any at all. For example, queries can be pre-compiled and no additional runtime is required.

Metadata Modeling AppModeling Language Guide P U B L I C 25

Annotations

Annotations are not a core feature of CDS and can/should be managed separately from the types and entities in the catalog. On one hand, this is because activation through the catalog/SQL is likely an expensive operation as compared to adding annotations which are not evaluated at all.

Another reason is that annotations are independent from the actual data models (and vice versa): A separate Annotation Service could allow you to annotate anything which can be identified by unique names.

5.1.1.2 Key Design Principles

1. CDS Is Not an Abstraction!

CDS does not abstract from underlying database features or 'shield' developers from SQL, which is in contrast to most persistence frameworks, especially object-relational mappers. We do want developers to use SQL and hence leverage its strengths instead of seeking refuge in abstractions. This applies to models as well as runtime:

The canonic mapping to SQL is part of the specification and applies common practices: Generated tables/views are as close as possible to how one would have done 'that' manually.

Everything being defined through CDS can always be consumed through native SQL! (i.e. including any vendor-specific extensions)

2. Zero Runtime Overhead

CDS does not introduce a data access layer, neither with respect to how queries are expressed, nor to how results are represented. Queries are expressed in SQL, to which CDS adds only careful extensions, which can be unfolded to plain SQL in pre-compilers and/or implemented natively in SQL engines (as we do in SAP HANA).

3. Zero Lock-in

CDS does not assume a certain environment or depend on any platform technology or programming language. You can use it with the technology stacks you choose. We thereby want to promote interoperability and reduce fragmentation in landscapes with increasingly heterogeneous technology stacks.

4. Non-Intrusive Use

CDS does not impose a programming model or force you into an all-or-nothing game. Its features are largely independent from each other and can be used individually and easily be combined with other technologies. For



example, you could import CDS data models into a JPA-based application, while not using CDS QL/SQL, annotations or the other features at all.

5. Applying Proven Standards

CDS does not invent anything new or enforce new paradigms. It is primarily based on and borrows from proven standards and methods like SQL and Entity-Relationship Modeling. The interesting thing is that this even more allows CDS to be combined with technologies that do invent new paradigms, definitely more than if CDS came with its own.

5.1.2 CDS Definition Language (CDL)

The CDS Definition Language allows you to define conceptual data models in the form of Entity-Relationship Models.

A typical example might look like this:

entity Orders { key ID : Integer; product : Association to Products; price : Amount; tax : Decimal(2,2); total = price.value * (1+tax);}type Amount { value : Decimal(10,3); currency : Currency;}entity Currencies { key code : String(3); name : String(44);}type Currency : Association to Currencies;entity Products as SELECT from Material mixin { campaign : Association to Campaigns on category = campaign.pcat } into { *, unitPrice * (1 - campaign.discount) as price}

Overview

We use a derivate of Extended Backus–Naur form (EBNF) for syntax definitions (see Syntax Notation for more information).


CDS data models consist of a number of definitions which can be one of the following kinds:

● Entity Definitions – representing queryable sets of data (including views)● Type Definitions – for reuse in elements of entities● Aspects/Extensions – applied to entities or types as mixins● Annotation Vocabularies – to declare and validate typed annotations

Entities are structured types with named and typed elements. The type of elements can in turn be:

● Scalar – derived from one of the Built-in Types● Structured – for example, Orders:price in the example above● Associations – capturing relationships to other entities

In total, these concepts constitute the CDS Type System as depicted below:

Names and Contexts

Each top-level definition is globally identified by a unique absolute name. To avoid always typing fully-qualified names, the following can be used:

● context a.b.c {...} prefixes names of nested definitions with a.b.c.● context a.b.c; directive at the beginning applied to the whole file● using x.y.z as z declares z as a shorthand alias for x.y.z.



For example:

context foo.bar; //> like context foo.bar {...} for all below using some.other.context as soc;using some.other.Entity as soe;entity Foo { ... } //> foo.bar.Foo { ... }type Zoo : soc.Zoe; //> foo.bar.Zoo : some.other.context.Zoe context sue { entity Car as //> foo.bar.sue.Car as SELECT from soe; //> SELECT from some.other.Entity}

Name Resolution

(Relative) names are always looked up in the inner-most lexical {...} scope first and then up to the file scope, but not beyond. This combined with the restriction, that using does not support a using x.y.* mode, guarantees, that bindings are not accidentally impacted through 'remote' changes / additions in other modules.

Some examples:

context foo; type Foo : String;type Boo : Integer;context bar { type X : Foo; //> resolves to foo.bar.Foo (below) type Y : :Foo; //> resolves to foo.Foo (above) type Z : Boo; //> resolves to foo.Boo (above) entity Foo { ... }}

The colon-prefix in :Foo is an operator that forces name resolution to start in the next outer scope.

Definitions

Definitions are expressed through statements like define entity Foo <details>, in which the leading keyword define is the default and can be omitted.

The specified name is relative in the current context and can itself be qualified, for example:

context foo.bar; context boo { entity full.Moon {...} //> foo.bar.boo.full.Moon}

See Entity Definitions for further details.

Expressions

In general, CDL inherits expressions from SQL of underlying databases. That is, depending on the occurrence, you can use all functions and operators your database supports.


In addition, all implementations of CDS are expected to support the following operators (in order from highest to lowest precedence):

NOT ||* / + -< <= > >== == != <> IS IS NOT IN LIKE AND OR

Lexical Conventions

Keywords and Identifiers

CDS is case-insensitive re keywords and (unquoted) identifiers, i.e. FOO, Foo and foo would all refer to the same thing.

Literals

CDL supports the following literals:

Table 5:

Strings as in SQL, i.e. in single(!) quotes 'a String'

Numbers as in SQL -7.99e3

Arrays as in JavaScript [ 11, 'car']

Records as in JavaScript { foo:11, bar:'car'}

Enumeration symbols prefixed with # #asc, #desc

Global constants null, true, false

Comments

CDL supports C-style comments, as well as SQL-style:

Table 6:

/*...*/ block comment (can span multiple lines)

//... line-end comment

--... line-end comment



Punctuation

The elementary symbols in CDL are used as in, for example, JavaScript:

● Curly braces { ... } enclose record-like structures, for example, an entity’s elements.● Round parenthesis ( ... ) enclose lists of parameters/arguments.● Square brackets [ ... ] are used for array literals.● Colons : precede type specifications, such as in element definitions.● Semicolons ; delimit definitions.

Colons before and semicolons after {...} blocks are optional. Moreover, colons directly before the = in calculated fields are optional.

Syntax Notation

5.1.3 Language Elements

The following sections describe CDS language elements.

5.1.3.1 Built-In Types

You can use the following built-in types in your definitions:

● The native SQL types of your underlying database (for example, varchar, ...)● The CDS built-in types listed below


Table 7:

Constructor Description

String(n) Variable-length unicode string with a maximum length of 5000

Binary(n) Variable-length binary data with a maximum length of 5000

Decimal(p,s) Number with fixed precision in range 1 to 34 and a scale of 0 to p

Integer Alias for integer32; may be redirected to a larger integer in the future

Integer32 Signed 32-bit integer with a value range of -2^31 to 2^31-1.

Integer64 Signed 64-bit integer with a value range of -2^63 to 2^63-1.

Date Local date with values ranging from Jan 1, 0001 through Dec 31, 9999

Time Time values with second precision and values ranging from 00:00 to 23:59:59

DateTime UTC date and time with seconds precision and values ranging from Jan 1, 0001 00:00:01 through Dec 31, 9999 23:59:59

Timestamp UTC date and time with micro seconds precision and values ranging from January 1, 0001 00:00:00 through December 31, 9999 23:59:59.9999999

5.1.3.2 Entity Definitions

Entities are the primary subjects of your metadata model, representing queryable sets of data.

Examples:

context cds.xmples; type Currency : Association to Currencies;entity Payslip { key ID : Integer; employee : Association to Employees; netAmount : { value : Decimal; currency : Currency; } taxrate : Decimal(3,2) default 0.19; grossAmount : type of netAmount = { value = (1.0 + taxrate) * netAmount.value, currency = netAmount.currency } kind : String(7) enum { regular; bonus; }}entity org.Employees { name: String, ... }



The following is the relevant excerpt from the Definition Language syntax:

All entities have a signature of a structured type with named and typed elements. They can be defined:

● By declaring their type structure explicitly, and/or● As projections, that is views on underlying entities

One or more elements can be qualified with key to specify an entity's primary key.

Entity Types = Structured Types

Entities—and structured types in general—contain zero or more element definitions enclosed in {...}. Each of which can start with the prepended keyword element, but that is optional.

entity Payslip { //> an entity key ID : Integer; employee : Association to Employees; netAmount : { //> an inline structured type value : Decimal; currency : Currency; } taxrate : Decimal(3,2) default 0.19; grossAmount : type of netAmount = (1.0 + taxrate) * netAmount; kind : String(7) enum { regular; bonus; }}

In general, an element definition always has the following simplified form:

[modifiers] name : Type Declaration [tail clauses]

with the Type Declaration as described below, and modifiers and tail clauses as follows:

Table 8:

Modifier Marks an element as...

key (part of) the entity’s primary key

const always having the specified constant value


Modifier Marks an element as...

masked hidden, i.e. being ignored by select *

virtual a virtual element

Table 9:

Tail Clauses Description

= expr For calculated elements: applied on select

default expr Same as in standard SQL: applied on insert

enum {...} Specifies a set of possible values with symbolic names

Type DeclarationsMost frequently an element’s type is derived from one of the built-in types or from a custom-defined one. Some of the built-in types accept parameters. Examples are:

entity Foo { name : String(44); netAmount : Amount; //> referring to custom-defined type Amount (a struct) taxrate : Decimal(3,2); }

Elements can also be specified with inline structured types as in:

entity Foo { netAmount { value: Decimal; currency: Association to Currencies; } }

See Path Expressions about how to address nested elements in queries

Finally you can use the type of operator to infer the type from another element’s type:

entity Foo { grossAmount : type of netAmount;}

NoteThe type names after type of are resolved from the inner most {...} scope. Use a : prefix, in case a name in that scope shadows the definition in an outer scope you want to refer to. For more information, see Name Resolution in the CDS Definition Language (CDL) topic.

Virtual/Calculated ElementsVirtual elements have no data stored in the database but are always calculated at runtime, that is query execution time. They are read-only in a sense that no other values can be written to them.

CDL supports two levels as shown here:

entity Foo { virtual pure : Integer; // to be filled by application logic on top



virtual calc : Date = now(); // filled by SQL queries (not persisted)}

Pure virtual elements are marked with the virtual modifier but do not have a calculation expression specified. They are used to declare elements whose values will be calculated by application logic on top of SQL/CDS. On database level, they do not exist at all and will never be returned in result sets of queries. The reason to still declare them in models is to provide hooks for annotations, for example, for use in generic clients.

Calculated elements have a calculation expression specified through = expr, which will be evaluated by the query runtime in SQL/CDS. They may optionally be marked with the virtual modifier, which does not have any additional effect, though. The calculation expressions can be applied to scalar elements as well as to structs as shown in this example:

entity Payslip { ... today : Date = now(); amount1 : { value : Decimal(10,2); currency : String(3); }; amount2 : = amount1; amount3 : type of amount1 = { currency: amount1.currency } } ● today is a scalar calculated element.● amount2 is a structured one that always has the same value(s) as amount1.● amount3 is also structured but only amount3.currency is calculated, while amount3.value will be a

standard, persisted element.

Type Inference – Explicit type declarations may be omitted for calculated fields, if, and only if, a type – including relevant details, e.g. dimension of a string, precision/scale of a decimal – can unambiguously be inferred from a given expression. Note that this is not possible for string types used in entity definitions as the maximum length parameter for the string would not be possible to infer through expressions.

ConstantsConstants are similar to calculated elements but with a guaranteed constant value. They can be defined using the same syntax as for calculated fields prepended with the modifier const. For example:

const female = 'female'; const male = 'male';

Constants are essentially just named symbols for literals, which can be used by name wherever a literal value can show up in CDL. They do not show up in persistence or in runtime structures. They are merely symbols used by the compiler; no value can be assigned at runtime. The expressions must be resolvable to a literal value at compile time.

Enumerated ValuesEnumerated values are defined using key word enum followed by a list of values. For example:

type gender : String(10) enum { male = ‘male’, female = ‘female’}

Default ValuesThe default expr clause is a 1:1 pass-through of the same clause in standard SQL.


Corresponding default values are inserted if no other value is specified upon inserting a new row. Most often single literals are specified, but the expression can also contain function calls and/or references to other elements within the same entity.

Views = Projections

Views are entities defined as projections on other entities – basically the equivalent of SQL views, and as those using SQL SELECT statements, including CDS QL enhancements. From a consumer’s perspective a view’s signature is indistinguishable from an entity’s signature.

Example:

entity EmployeesView as SELECT from Employees { id, name, salary, orgunit.{ manager, name as orgunit, }}

As in to SQL you can use view instead of entity – both are equivalent.

Inferred Signatures – Views are entities, with their signature usually inferred from the given projection. The inferred signature of the example above would resolve to that equivalent:

entity EmployeesView { id: Integer; name: String; salary: Amount; manager : Association to Employees; //> from orgunit.manager orgunit : String; //> from orgunit.name as orgunit}

Explicit Signatures – If required, you can explicitly specify the (expected) signature. In that case, the inferred signature will be checked against the expected one, and an activation error will be thrown if they would not match. For example:

entity EmployeesView { id: Integer; name: String; salary: Amount; //> expected signature } as SELECT from Employees { id, name, salary //> inferred signature}

Key Elements, etc. – Within the projection clause of view definitions you can prepend element clauses with the element modifiers key, virtual and/or masked. For example:

entity EmployeesViewWithKey as SELECT from Employees { key id, ...}

NoteIn contrast to entities, keys in views do not imply any uniqueness constraint. When defining a view, potentially required key elements must always be marked explicitly in the view; they are never implicitly derived from the underlying entities.



Primary Keys

In general, each entity must specify a primary key, that is, an attribute combination that uniquely identifies instances. The order of appearance of key elements within an entity definition determines the order of the primary key attributes.

For example, this entity definition:

entity Address { key streetAddress : String(77); key zipCode : String(11); city : String(44); }

is equivalent to the following standard SQL definition:

CREATE TABLE "ADDRESS" ( "STREETADDRESS" nvarchar(77) not null, "ZIPCODE" nvarchar (11) not null, "CITY" nvarchar (44) constraint $primaryKey primary key ("STREETADDRESS", "ZIPCODE"))

If a struct-typed element is denoted as key, all database columns representing the nested fields of this structure are part of the primary key.

Reuse Types

You can define global, named types for reuse as in this example:

context cds.xmples; type Currency : Association to Currencies;type Amount : { value : Decimal; currency : Currency; }entity Payslip { ... netAmount : Amount; }

The same options are available as described above for element types, except for the element modifiers.

5.1.3.3 Associations

In CDS-based models, we add associations by adding an element to a source entity with an Association type that points to a target entity. The most basic form expects a fully specified join condition. We call this form unmanaged associations.

Examples:

entity Employees { ...


key ID : Integer; address_id : Integer; address : Association to one Address on address.ID = address_id; addresses : Association to many Addresses on addresses.owner = ID;}

Syntax:

Association = | Association to [one|many] target [joinspec] | Association [cardinality] to target [joinspec]cardinality = [ [ maxs, ][ min .. ][ max ] ]joinspec = on <expr>target = QualifiedName -- expected to resolve to an entity

Analysis:

As explained above, associations are elements with an Association type. Hence, Association is not a keyword but the name of a built-in type, similar to String or Decimal. And as with those, it accepts a set of parameters in SQL-like parameter clauses style.

● to [one | many] targetSpecifies the association’s target. A qualified name referring to an entity is expected. This is the only mandatory parameter. In case the target is a table function or a view with parameters, arguments can be appended in parenthesis ([args]).

● [ on expr ]Is a standard SQL join condition. Names in the on condition are always resolved from the source entity’s scope; all references to elements in the target must be prefixed with the association name, for example, address.ID.

● [one | many] or [cardinality]Allows you to optionally specify the relationship’s cardinality. Essential for CDS is only whether it is to one / [*,0..1] (= the default) or to many / [0..*]. Usually only the target-side cardinality is specified. Source-side can be specified as a hint to the optimizer if required, for example, [1,0..*]. [] == to many == [0..*]

5.1.3.4 Compositions

Compositions are associations representing contained-in relationships, such as in SalesOrder(Header) and OrderItems. While the effective concepts are those of associations, a specific and more concise syntax variant is offered to better capture the semantics.

Examples:

entity SalesOrders { description: varchar(111); Items : Composition of many { product : Association to Products; quantity : Integer; }}

Syntax:

Association += | Composition [ cardinality ] of (target)



| Composition of [ one|many ] (target)

Analysis:

The Composition of syntax is a convenient shortcut for defining individual entities with involved associations. The example above would be expanded to:

entity SalesOrders { description: varchar(111); Items : Composition of many SalesOrders.Items on Items.parent=self;}entity SalesOrders.Items { parent : Association to SalesOrders; product : Association to Products; quantity : Integer;}

The anonymous type in the nested definition is expanded to a type with the qualified name <name of parent entity>.<name of composition element> . Alternatively, the non nested option can be used as in the expanded version above. In that case, the alternative keywords merely result in the association being flagged as a composition association in the model’s metadata.

Associations to self

The pseudo variable self refers to the current entity and can be used wherever an association to the own entity (current instance) is required. For example, self is frequently used to define one-to-many associations:

entity Employees { ... key ID : Integer; addresses : Association to many Addresses on addresses.owner = self;}entity Addresses { ... owner : Association to Employees;}

Think of self as an implicitly defined self-join association for each entity as follows:

entity <Entity> { ... masked self : Association to <Entity> on self.<primarykey> = <primarykey>;}

5.1.3.5 Redirecteds

Redirecteds define the association or composition in the service the same way as they are defined in the models.

entity DeliveryItem as projection on DeliveryModel.DeliveryItem { *, storageLocation.locationId as storageLocation @title:'Storage Location', delivery : redirected to DeliveryProcess };


5.1.3.6 Annotations

Annotations allow you to augment data models with additional metadata, which can be introspected at runtime. They are triples of:

● A property – the key or name identifying a specific piece of metadata● A target – i.e. types, entities, views and elements thereof● A value – the actual metadata

In the context of CDS, targets are entities or views and elements thereof. For example:

@Some.header.property: ‘SomeValue’ entity SomeTarget { element someElementInTarget @<Some.element.property: 4711;}

Annotation vocabularies declare typed schemas for annotations which allow you to check annotations and provide tool support such as hints and code completion in editors. Whether to use or mandate vocabularies can be decided on project level. The core annotation service also allows annotations without vocabularies in place.

Assigning Annotations

Within CDS metadata model definitions, types, entities and views as well as individual elements thereof can be annotated as shown in the following examples.

@UI.label: ‘Customer’ entity Customer {name : String(44) @<UI: { label: ‘Customer Name’, localized: [{ lang: ‘de’, label: ‘Kundenname’ }]};...}@UI.label: ‘Customers’view SalesView as SELECT from SalesOrders {buyer.name as customer @<UI.label: ‘Customer’, ...}// or in a separate metadata extension:@UI.label: ‘Customers’annotate SalesView with {customer @<UI.label: ‘Customer’; ...}

Syntax:

Hooks into SDL syntax rules

TypeDefinition = [@pre] type typeName <…> [@post] [";"] EntityDefinition = [@pre] entity entityName <…> [@post] [";"]ViewDefinition = [@pre] view viewName <…> [@post] [";"]ElementDefinition = [@pre] [ key ][ masked ][ element ] elementName <…> [@post] [";"]ParameterDefinition = [@pre] parameterName <…> [@post]

Annotations syntax

@pre = ( "@" Annotation )*



@post= ( "@<" Annotation )*Annotation = PropertyName [ ":" AnnotationValue ]AnnotationValue = Literal | null PropertyName = QualifiedName [ "#" VariantQualifier ]VariantQualifier = Identifier

Analysis:

Annotations can be applied to definitions within SDL documents. Possible targets are the signature of all kind of definitions, such as types, entities and views on header level, as well as individual elements and parameters in structured types, entity and view definitions. Two syntax options are supported: either before a target definition each prefixed with a “@”, or in case of elements after the definition, immediately before the delimiter – i.e. “;” in case of type and entity definitions and “,” in case of query elements in view definitions (except the last one). Suffixed annotations start with a “@”, followed by a “<” (no space in between). For example:

@Some.annotation: 4711 entity Foo { @Field.annotation: 'bar' foo : String(44);}

is equivalent to:

@Some.annotation: 4711 entity Foo { foo : String(44) @<Field.annotation:'bar';}

Allowed values for annotations are:

● Literals, i.e. strings, numbers, true, false, enum symbols, records and arrays● The atoms null● Expressions

Most frequently literal values or null are assigned statically. Assigning expressions are used to express conditions which lead to dynamically resolved values. If no value is specified at all, true is implicitly assigned. This is a shorthand to allow for intuitive annotations such as:

entity Foo { foo : String(44) @<mandatory;}

Assigning Records

The annotation service ultimately stores only scalar values. Yet, we can assign records, which is a syntactical shortcut for annotations with common prefixes. For example, the following three annotations are equivalent, with the former two simply being shortcut notations for the third one:

@UI: { field: { label: ‘Customer’, width: 22 }} [email protected]: { label: ‘Customer’, width: 22 }[email protected]: ‘Customer’@UI.field.width: 22


Among others this is important to keep in mind when overriding annotations in derived types, views or extensions. For example, the following annotation on a derived type would override the width while the label would still remain 'Customer':

@UI.field: { width: 33 }

That is, this annotation does not override the complete record for @UI.field, as it is just a shortcut notation for @UI.field.width: 33.

Assigning Arrays

The annotation service ultimately stores only scalar values. The assignment of record and array literals are syntactical shortcuts for annotations with common prefixes. For example, the following three annotations are equivalent, with the former two simply being shortcut notations for the third one:

@UI: { label: ‘First Name’, localized: [ { lang: ‘fr’, label: ‘Prénom’ },{ lang: ‘de’, label: ‘Vorname’ }]}@UI.localized.lang: ‘fr’@UI: {localized: [{ lang: ‘fr’ },]}

is equivalent to:

@UI.label: ‘First Name’, @UI.localized.1.lang: ‘fr’,@UI.localized.1.label: ‘Prénom’,@UI.localized.2.lang: ‘de’,@UI.localized.2.label: ‘Vorname’

See Introspecting Annotations for further information on obtaining annotation records and arrays at runtime.

5.2 GTT Metadata Model with CDS

Track and Trace leverages CDS to provide the generic tracked process and event metadata model and to allow applications to model their own, domain specific processes and events. To do so, CDS is used in a specific way which is described in this chapter.



5.2.1 Overall Structure

The generic tracked processes and events are provided as entities with a set of common fields which are ready to be included via extension in application specific models.

Namespaces and Files

The generic metadata is provided in a set of separated CDS files whose content can be referenced within application specific metadata definitions. In addition, some reusable data types from SAP IoT Application Enablement are being reused and provided within the generic metadata part.

The figure below shows the file structure.

The core model uses some data types and entities from the SAP IoT Application Enablement. An application, for example, a delivery application or shipment application provides

● A model definition that defines the metadata model of tracked processes and events for a particular application

● A service definition that exposes the metadata model to be consumed by OData services● A UI annotation file that allows usage of SAP Fiori Elements as generic UI for applications. The advantage is

that applications do not need to write their own user interfaces but can leverage proven SAP technology.

To distinguish entities and types we have to have namespaces. For the core model, the namespace is fixed and set to com.sap.gtt.core. SAP applications use application specific namespaces below structuring namespace com.sap.gtt.app, for example, com.sap.gtt.app.deliverysample. Custom specific applications have to use a custom owned namespace, for example, com.<customer name>.gtt.app.


Core Model

The core model can be represented with the following graphic.

Within the core model the tracked process defines the necessary core properties that make a process a tracked process. Each tracked process has a set of qualified tracking ids linked. Whenever an event is reported with a particular tracking ID, all instances that have that particular tracking ID assigned are considered to be affected by the event. Assignment of tracking IDs is time dependent.

The entity event is a generic entity without specific business semantic beside the event itself with actual data when the event happened.

The link between tracked processes and events is the process event directory, which actually serves two purposes. First, to store a map of planned events and second, to store actual events that either match a planned event or become an unplanned event.



The core service exposes the necessary core entities to consumers like OData. The Core UI provides UI annotations usable for SAP Fiori Elements to ensure consistent user experience across all applications within the SAP Global Track and Trace solution.

Application Model

Based on the core model, an application can define its own model that consists of three parts (a simple mode application model only consists of the first part):

1. The metadata model itself that extends tracked processes and events with additional business domain specific data

2. The application service that exposes the metadata model to OData consumers like UI3. The UI annotations for SAP Fiori Elements

Continuing the example of the delivery application, this will result in the following structure:

The delivery process extends the abstract core tracked process by adding new fields for business related data.

The delivery service extends the core service and exposes the newly defined entities as required to the UI. The UI annotation file may include the core UI definition file to re-use certain default configurations for entities from the core model to ensure proper and common user experience across applications.


5.2.2 Core Model Details

Core Model consists of four files:

Table 10:

File Name Name Space Context/Service Purpose

CoreModel.cds com.sap.gtt.core CoreModel Defines the annotations and entities used by the core engine.

CoreServices.cds com.sap.gtt.core CoreService Exposes the necessary entities as service and provides the UI annotations for SAP Fiori Elements.

CoreTypes.cds sap.appcore.cs.i CoreTypes Defines the types used by the core model and other metadat models.

CoreAnnotations.cds Not applicable Multiple contexts Defines the general annotations used by the core engine and application layer model.

Sample Core Model Files

CoreModel.cds

namespace com.sap.gtt.core; // Reuse IoT AS data typesusing sap.appcore.cs.i.CoreTypes from "CoreTypes";using sap.appcore.bp.p.BusinessPartner from "BusinessPartner-Dummy";using sap.appcore.loc.p.Location from "Location-Dummy";context CoreModel { // Remarks for naming: // According to API rules names have to follow field names from Global Field Catalog // This has to be done for all fields once a common naming is agreed on ///////// // Annotations // ---------------------------------------------------------------------- annotation ObjectIdentifierType : String(255) enum { // object identifier type code as given in key mapping // ObjectIdentifierType for Business Partner customer = 'customer'; vendor = 'vendor'; businessPartner = 'businessPartner'; others = 'others'; // ObjectIdentifierType for Location customerLocation = 'customer location'; vendorLocation = 'vendor location'; shippingPoint = 'shipping point'; plant = 'plant'; };



annotation UsageType : array of String(255) enum { // type of usage of an view inboundMessage = 'inboundMessage'; userInterface = 'userInterface'; search = 'search'; searchResult = 'searchResult'; }; annotation MainEntity : Boolean; annotation StatusProperties : array of String; @inherit: false annotation Indexable : Boolean; annotation BaseType : String(255) enum { TrackedProcess = 'TrackedProcess'; Event = 'Event'; BusinessPartner = 'BusinessPartner'; Location = 'Location'; }; // Annotations for map // ---------------------------------------------------------------------- context Map { context CurrentProcessLocation { annotation Longitude : Boolean; annotation Latitude : Boolean; annotation UpdateTimestamp : Boolean; } }; // Annotations for simple mode project // ---------------------------------------------------------------------- annotation SemanticKey : Boolean; annotation MapEnabled : Boolean; annotation ShowCriticality : Boolean; context SortOrder { annotation ByField : String; annotation Descending : Boolean; }; context SearchFields { annotation FilterFields : array of String; annotation ResultFields : array of String; }; annotation LayoutGroups : array of { GroupName : String; Label : String; Data : array of String; }; context LayoutFacets { annotation Header : array of String; annotation Main : array of String; annotation Sublists : array of String; }; // Most generic data without any business semantics // ideally part of some IoT AS Core Services // ---------------------------------------------------------------------- type UnitOfMeasure : String(6); type TimeZoneCode : String(50); entity TimeZone { key timeZoneCode : TimeZoneCode @title: 'Time Zone' @Common:{ Text: description, TextArrangement: #TextFirst }; description : String(255) @title: 'Description'; }; type ValidityStartTimestampUTC : Timestamp; type ValidityEndTimestampUTC : Timestamp; type LogicalSenderSystem : String(10); // tracked entity as abstract subsumption of Tracked object / tracked process data // ---------------------------------------------------------------------- type TrackedProcessId : CoreTypes.Uuid; type TrackedProcessType : String(255); // Integration with SAP Event Management


// ---------------------------------------------------------------------- type EventId : CoreTypes.Uuid; type EventCode : String(20); // Object identification via tracking ID and external ID // ---------------------------------------------------------------------- type TrackingId : String(50); type TrackingIdType : String(40); entity QualifiedTrackingId { key trackedProcess : Association to one TrackedProcess; sender : Association to one BusinessPartner.BusinessPartner @title: 'Sender'; logicalSenderSystem : LogicalSenderSystem @title: 'Sender System'; key trackingIdType : TrackingIdType @title: 'Tracking ID Type'; key trackingId : TrackingId @title: 'Tracking ID'; validFromUTC : ValidityStartTimestampUTC @title: 'Valid From'; validToUTC : ValidityEndTimestampUTC @title: 'Valid To'; isPrimaryId : Boolean @title: 'Primary ID'; }; // Status Values in General // ---------------------------------------------------------------------- annotation KeepStatusSequence : Boolean; annotation UpdateStatus : array of { pathToStatus : String(255); newValue : String(255); }; // Event Map and unplanned events // ---------------------------------------------------------------------- type EventSequence : Integer; entity EventStatus { key Code : String(10) @title:'Status Code' @Common:{ Text: Text, TextArrangement: #TextOnly }; Text : String(50) @title:'Status Name'; Criticality : Integer @Common.FieldControl:#Hidden; EditEnabled : Boolean @Common.FieldControl:#Hidden; }; type EventReasonText : String(255); entity PersonalDataProtectionStatus { key Code : String(10) @title:'Status Code' @Common:{ Text: Text, TextArrangement: #TextOnly }; Text : String(50) @title:'Status Name'; }; // The annotation used to assign planned events to a tracked process annotation PlannedEvents : array of { eventType : String(255); matchLocation : Boolean; technicalToleranceValue : String(50); businessToleranceValue : String(50); }; annotation AdmissibleUnplannedEvents : array of { eventType : String(50); }; // Entities used for object tracking entity HierarchyNode { key process : Association to one TrackedProcess; @sap.hierarchy.node.for: 'nodeid' @title: 'Node' key node : Association to one TrackedProcess; @sap.hierarchy.parent.node.for: 'nodeid' @title: 'Parent Node' parent : Association to one TrackedProcess; validFrom : Timestamp @title: 'Valid From'; validTo : Timestamp @title: 'Valid To'; @sap.hierarchy.level.for: 'nodeid' @title: 'Level' hierarchyLevel : Integer;



@sap.hierarchy.drill.state.for: 'nodeid' @title: 'Drill State' drillState : String(10) enum { collapsed = 'collapsed'; expanded = 'expanded'; leaf = 'leaf'; }; }; entity ObjectReference { key id : CoreTypes.Uuid; key event : Association to one Event; obsType : String(50) enum { //parentStart = 'parentStart'; //parentEnd = 'parentEnd'; //childStart = 'childStart'; //childEnd = 'childEnd'; parent = 'parent'; child = 'child'; }; objKey : String(255); }; // Tracked Process as one and only tracked "something" // ---------------------------------------------------------------------- @CoreModel.BaseType: #TrackedProcess abstract entity TrackedProcess { // Unique identifier - common for T&T and also for IoT AS it's a UUID key id : TrackedProcessId; masked tenant : CoreTypes.Tenant not null; name : CoreTypes.Name; description : CoreTypes.Description @title: 'Description'; // fields for T&T trackedProcessType : TrackedProcessType; trackingIds : Composition of many QualifiedTrackingId on trackingIds.trackedProcess = $self @title: 'Qualified Tracking IDs'; sender : Association to one BusinessPartner.BusinessPartner @title: 'Sender'; logicalSenderSystem : LogicalSenderSystem @title: 'Sender System'; trackingIdType : TrackingIdType @title: 'Tracking ID Type'; trackingId : TrackingId @title: 'Tracking ID'; processEvents : Composition of many ProcessEventDirectory on processEvents.process = $self; lastProcessedEvent : Association to one ProcessEventDirectory { processEventDirectoryId }; hierarchy : Association to many HierarchyNode on hierarchy.process = $self; personalDataProtectionStatus : String(20) @title: 'Data Retention Status' enum { businessActive = 'BA' @title: 'Business Active'; endOfBusiness = 'EOB' @title: 'End of Business'; endOfPurpose = 'EOP' @title: 'End of Purpose'; endOfRetention = 'EOR' @title: 'End of Retention'; } default 'BA'; // Administrative Data //systemAdminData : CoreTypes.SystemAdminData; CreatedByUser : String(64); CreationDateTime : Timestamp; LastChangedByUser : String(64); LastChangeDateTime : Timestamp; }; // The event directory per tracked process


// ------------------------------------------------------------------------------ entity ProcessEventDirectory { key process : Association to one TrackedProcess; key processEventDirectoryId : CoreTypes.Uuid; // This is NOT the id of the event masked tenant : CoreTypes.Tenant not null; eventCode : EventCode @title:'Event Code'; eventType : String(255) @title:'Event Type'; eventStatus : String(50) @title: 'Event Status' enum { planned = 'PLANNED' @title: 'Planned' @Criticality: 0 @EditEnabled: true; reported = 'REPORTED' @title: 'Reported' @Criticality: 3 @EditEnabled: true; unplanned = 'UNPLANNED' @title: 'Unplanned' @Criticality: 1 @EditEnabled: false; overdue = 'OVERDUE' @title: 'Overdue' @Criticality: 2 @EditEnabled: true; }; eventReasonText : EventReasonText @title:'Event Reason'; event : Association to one Event; // Plan Data sequence : EventSequence; //@Common.SemanticObject: 'Location' location : Association to one Location.Location @title:'Location'; // planned technical time & date plannedTechnicalTimestampUTC : Timestamp @title:'Planned Technical Time'; plannedTechTsEarliestUTC : Timestamp @title:'Earliest Planned Technical Time'; plannedTechTsLatestUTC : Timestamp @title:'Latest Planned Technical Time'; // planned business time & date @TimeZoneInfo.TimeZone: plannedBusinessTimeZone plannedBusinessTimestampUTC : Timestamp @title:'Planned Business Time'; @TimeZoneInfo.TimeZone: plannedBusinessTimeZone plannedBizTsEarliestUTC : Timestamp @title:'Earliest Planned Business Time'; @TimeZoneInfo.TimeZone: plannedBusinessTimeZone plannedBizTsLatestUTC : Timestamp @title:'Latest Planned Business Time'; @Semantics.TimeZone: true plannedBusinessTimeZone : Association to one TimeZone @title:'Planned Business Time Zone'; // Actual Event Data // ToDo: Partially redundant with event data => to be sorted out based on access patterns actualTechnicalTimestampUTC : Timestamp @title:'Actual Technical Time'; @TimeZoneInfo.TimeZone: actualBusinessTimeZone actualBusinessTimestampUTC : Timestamp @title:'Actual Business Time'; @Semantics.TimeZone: true actualBusinessTimeZone : Association to one TimeZone @title:'Actual Business Time Zone'; // Administrative Data //systemAdminData : CoreTypes.SystemAdminData; CreatedByUser : String(64) @title: 'Created By'; processingTimestampUTC : Timestamp @title: 'Created At'; }; // Events and Event Messages: // Idea is to define the events only - // a corresponding Event Message has equivalent data // ------------------------------------------------------------------------------ @CoreModel.BaseType: #Event



entity Event { // Unique identifier - common for T&T and also for IoT AS it's a UUID key id : EventId; masked tenant : CoreTypes.Tenant not null; // Fields for T&T Event Model eventCode : EventCode @title:'Event Code'; eventType : String(255) @title:'Event Type'; eventReasonText : EventReasonText @title:'Event Reason'; senderParty : Association to one BusinessPartner.BusinessPartner @title: 'Event Sender'; //trackingId : EventQualifiedTrackingId; sender : Association to one BusinessPartner.BusinessPartner @title: 'Sender'; logicalSenderSystem : LogicalSenderSystem @title: 'Sender System'; trackingIdType : TrackingIdType @title: 'Tracking ID Type'; trackingId : TrackingId @title: 'Tracking ID'; // Actual Event Data actualTechnicalTimestampUTC : Timestamp; @TimeZoneInfo.TimeZone: actualBusinessTimeZone actualBusinessTimestampUTC : Timestamp @title:'Actual Business Time'; @Semantics.TimeZone: true actualBusinessTimeZone : Association to one TimeZone; //@Common.SemanticObject: 'Location' location : Association to one Location.Location @title:'Location'; // adHoc location fields locationId : String(255); locationDescription : CoreTypes.Description; // TODO: localized longitude : Decimal(9,6); latitude : Decimal(8,6); objectReferences : Composition of many ObjectReference on objectReferences.event = $self; // Administrative Data messageSourceType : String(50); CreatedByUser : String(64) @title: 'Created By'; processingTimestampUTC : Timestamp @title: 'Created At'; }; // Predefined Event for Overdue // ---------------------------------------------------------------------- @UI.HeaderInfo.Title.Label: 'GTT Overdue' @SAP_EM.eventCode: {Code: 'GTT_OVERDUE', Text: 'Overdue', Type: 'UNPLANNED' } @CoreModel.Indexable: true entity GTTOverdueEvent : CoreModel.Event { process : Association to one TrackedProcess; plannedEvent : Association to one ProcessEventDirectory { processEventDirectoryId }; }; // Predefined Event for Personal Data Blocking // ---------------------------------------------------------------------- @UI.HeaderInfo.Title.Label: 'GTT Personal Data Blocking' @SAP_EM.eventCode: {Code: 'GTT_DPP_BLOCK', Text: 'Personal Data Blocking', Type: 'PLANNED' } @CoreModel.Indexable: true entity GTTPersonalDataBlockingEvent : CoreModel.Event { process : Association to one TrackedProcess; }; // Predefined Event for Personal Data Deletion // ---------------------------------------------------------------------- @UI.HeaderInfo.Title.Label: 'GTT Personal Data Deletion' @SAP_EM.eventCode: {Code: 'GTT_DPP_DELETE', Text: 'Personal Data Deletion', Type: 'PLANNED' } @CoreModel.Indexable: true entity GTTPersonalDataDeletionEvent : CoreModel.Event { process : Association to one TrackedProcess;


}; // // Entities for map function. Only used for odata services. // The data is computed on the fly. // entity ProcessLocation { key id : String(255); key process : Association to one TrackedProcess; location : Association to one Location.Location; pos : String(255); type : String(255); description : String(255); }; entity CurrentProcessLocation { key id : String(255); key process : Association to one TrackedProcess; pos : String(255); }; entity ProcessRoute { key id : CoreTypes.Uuid; key process : Association to one TrackedProcess; pos : String(5000); }; };

CoreServices.cds

namespace com.sap.gtt.core; using com.sap.gtt.core.CoreModel from "CoreModel";using sap.appcore.cs.i.CoreTypes from "CoreTypes";using sap.appcore.bp.p.BusinessPartner as bp from "BusinessPartner-Dummy";using sap.appcore.loc.p.Location as loc from "Location-Dummy";context CoreServices { @abstract context TrackedProcessService { extend entity CoreModel.Event with { @TimeZoneInfo.toLocalString: { UTCTimestamp: actualBusinessTimestampUTC, TimeZone: actualBusinessTimeZone } actualBusinessTimestampUTC_text : String(255) @Common.FieldControl: #Hidden; }; entity Event as projection on CoreModel.Event excluding { tenant }; entity GTTOverdueEvent as projection on CoreModel.GTTOverdueEvent excluding { tenant, plannedEvent }; entity HierarchyNode as projection on CoreModel.HierarchyNode; entity ObjectReference as projection on CoreModel.ObjectReference { *, event : redirected to Event }; entity GTTPersonalDataBlockingEvent as projection on CoreModel.GTTPersonalDataBlockingEvent excluding { tenant }; entity GTTPersonalDataDeletionEvent as projection on CoreModel.GTTPersonalDataDeletionEvent excluding { tenant }; entity QualifiedTrackingId as projection on CoreModel.QualifiedTrackingId; entity BusinessPartner as projection on bp.BusinessPartner excluding { tenant };



entity Location as projection on loc.Location; // Helper entities for ValueLists entity TimeZone as projection on CoreModel.TimeZone; entity EventStatus as projection on CoreModel.EventStatus; entity PersonalDataProtectionStatus as projection on CoreModel.PersonalDataProtectionStatus; extend entity CoreModel.TrackedProcess with actions { // Report Unplanned Event action ReportUnplannedEvent ( eventCode : String(20) not null @title: 'Event' @Common.FieldControl:#Mandatory @ValueList: {type: #fixed, entity: 'EventFilteredDescription'}, eventReasonText : String(255) @title: 'Reason' @Common.FieldControl:#Optional, @Common: { ValueList: { Label: 'Locations', CollectionPath: 'Location', SearchSupported: false, Parameters: [ { $Type: 'Common.ValueListParameterInOut', ValueListProperty: 'locationId', LocalDataProperty: 'locationlocationId', }, { $Type: 'Common.ValueListParameterOut', ValueListProperty: 'description', LocalDataProperty: 'locationDescription', } ] } } locationDescription : CoreTypes.Description @title: 'Location' @Common.FieldControl:#Optional, locationlocationId : CoreTypes.Uuid @Common.FieldControl:#Hidden, // Location UUID actualBusinessTimestamp : Timestamp not null @title: 'Actual Business Time' @Common.FieldControl:#Mandatory, @Common: { FieldControl: #Mandatory, Text: actualBusinessTimeZone, TextArrangement: #TextLast, // formatted as "Asia/Shanghai - China Time (UTC+08:00)" ValueListWithFixedValues: true, ValueList: { Label: 'Time Zones', CollectionPath: 'TimeZone', SearchSupported: false, Parameters: [ { $Type: 'Common.ValueListParameterInOut', ValueListProperty: 'timeZoneCode', LocalDataProperty: 'actualBusinessTimeZone', }, { $Type: 'Common.ValueListParameterDisplayOnly', ValueListProperty: 'description' } ] } } actualBusinessTimeZone : String not null @title: 'Actual Business Time Zone' ) returns String; }; extend entity CoreModel.ProcessEventDirectory with { // planned business time & date


@TimeZoneInfo.toLocalString: { UTCTimestamp: plannedBusinessTimestampUTC, TimeZone: plannedBusinessTimeZone } plannedBusinessTimestampUTC_text : String(255) @Common.FieldControl: #Hidden; // @TimeZoneInfo.toLocalString: { // UTCTimestamp: plannedBizTsEarliestUTC, // TimeZone: plannedBusinessTimeZone // } // plannedBizTsEarliestUTC_text : String(255) @Common.FieldControl: #Hidden; // @TimeZoneInfo.toLocalString: { // UTCTimestamp: plannedBizTsLatestUTC, // TimeZone: plannedBusinessTimeZone // } // plannedBizTsLatestUTC_text : String(255) @Common.FieldControl: #Hidden; // Actual Event Data @TimeZoneInfo.toLocalString: { UTCTimestamp: actualBusinessTimestampUTC, TimeZone: actualBusinessTimeZone } actualBusinessTimestampUTC_text : String(255) @Common.FieldControl: #Hidden; @TimeZoneInfo.toLocalTime: { UTCTimestamp: actualBusinessTimestampUTC, TimeZone: actualBusinessTimeZone } actualBusinessTimestamp : Timestamp @Common.FieldControl: #Hidden; // fake timestamp for the date time picker in report event UI }; entity ProcessEventDirectory as projection on CoreModel.ProcessEventDirectory { *, event : redirected to Event } excluding { tenant, // planned technical time & date plannedTechTsEarliestUTC, plannedTechTsLatestUTC, // planned business time & date plannedBizTsEarliestUTC, plannedBizTsLatestUTC }; extend entity ProcessEventDirectory with actions { // Report Planned Event @sap.applicable.path: 'to_eventStatus/EditEnabled' action EditEvent ( @Common.Text: to_eventCode.Text eventCodeText : String @title: 'Event' @Common.FieldControl:#ReadOnly, eventCode : CoreModel.EventCode not null @Common.FieldControl:#Hidden, @Common.Text: location.description locationDescription : CoreTypes.Description @title: 'Location' @Common.FieldControl:#ReadOnly, locationlocationId : CoreTypes.Uuid @Common.FieldControl:#Hidden, // Location UUID plannedBusinessTimestampUTC_text : String @title: 'Planned Business Time' @Common.FieldControl:#ReadOnly, actualBusinessTimestamp : Timestamp not null @title: 'Actual Business Time' @Common.FieldControl:#Mandatory, @Common: { FieldControl: #Mandatory, Text: actualBusinessTimeZone.description, TextArrangement: #TextLast, // formatted as "Asia/Shanghai - China Time (UTC+08:00)"



ValueListWithFixedValues: true, ValueList: { Label: 'Time Zones', CollectionPath: 'TimeZone', SearchSupported: false, Parameters: [ { $Type: 'Common.ValueListParameterInOut', ValueListProperty: 'timeZoneCode', LocalDataProperty: 'actualBusinessTimeZonetimeZoneCode', }, { $Type: 'Common.ValueListParameterDisplayOnly', ValueListProperty: 'description' } ] } } actualBusinessTimeZonetimeZoneCode : String not null ) returns String; }; // // Entities for Value Lists // entity EventDescription { key Code : String(20) @title: 'Event Code' @Common: { Text: Text, TextArrangement: #TextOnly }; Text : String(255) @title: 'Event Description'; }; entity EventFilteredDescription : EventDescription {}; // // Entities for map function // entity ProcessLocation as projection on CoreModel.ProcessLocation; entity CurrentProcessLocation as projection on CoreModel.CurrentProcessLocation; entity ProcessRoute as projection on CoreModel.ProcessRoute; };};//////////////////////////////////////////////////////////////////////////////// Annotations for Event//annotate CoreModel.Event with @( // Header-level Annotations Common.FilterExpressionRestrictions: [ { Property: actualBusinessTimestampUTC, AllowedExpressions: #SingleInterval, } ], UI.HeaderInfo: { TypeName: 'Event', TypeNamePlural: 'Events', Title: {Value: to_eventCode.Text}, }, UI.Identification: [ {Value: eventType}, ], UI.SelectionFields: [ eventType ], Capabilities: { Insertable: false, Updatable: false, Deletable: false, FilterRestrictions: {


NonFilterableProperties: [ ] }, SortRestrictions: { NonSortableProperties: [ ] }, SearchRestrictions: { Searchable: false }, },) { // Element-level Annotations @Common.Text: actualBusinessTimestampUTC_text @Common.TextArrangement: #TextOnly actualBusinessTimestampUTC;};// Line Items for Listsannotate CoreModel.Event with @( UI.PresentationVariant: { Visualizations: [ '@UI.LineItem' ], SortOrder: [ ], RequestAtLeast: [ ], }, UI.LineItem: [ {Value: eventType}, {Value: eventReasonText}, {Value: location}, {Value: actualBusinessTimestampUTC}, {Value: CreatedByUser}, {Value: processingTimestampUTC}, ]);// Facets for Object Pageannotate CoreModel.Event with @( UI.HeaderFacets: [ {$Type: 'UI.ReferenceFacet', Target: '@UI.FieldGroup#SenderInfo'}, {$Type: 'UI.ReferenceFacet', Target: '@UI.FieldGroup#TrackingInfo'}, ], UI.Facets: [ { $Type: 'UI.CollectionFacet', ID: 'DetailInfo', Label: 'Detailed Information', Facets: [ {$Type: 'UI.ReferenceFacet', Target: '@UI.FieldGroup#GeneralInfo'}, {$Type: 'UI.ReferenceFacet', Target: '@UI.FieldGroup#AdminData'}, {$Type: 'UI.ReferenceFacet', Target: '@UI.FieldGroup#CustomData'}, ] }, ], UI.FieldGroup#SenderInfo: { Label: 'Sender', Data: [ {$Type: 'UI.DataFieldForAnnotation', Label: 'Sender', Target: 'sender/@Communication.Contact'}, {Value: logicalSenderSystem}, ] }, UI.FieldGroup#TrackingInfo: { Label: 'Tracking ID', Data: [ {Value: trackingId}, {Value: trackingIdType},



] }, UI.FieldGroup#GeneralInfo: { Label: 'General', Data: [ {Value: location}, {Value: actualBusinessTimestampUTC}, {Value: eventReasonText}, ] }, UI.FieldGroup#AdminData: { Label: 'Administrative Data', Data: [ {$Type: 'UI.DataFieldForAnnotation', Label: 'Event Sender', Target: 'senderParty/@Communication.Contact'}, {Value: CreatedByUser}, {Value: processingTimestampUTC}, ] });//////////////////////////////////////////////////////////////////////////////// Annotations for ProcessEventDirectory//annotate CoreServices.TrackedProcessService.ProcessEventDirectory with @( // Header-level Annotations Common.FilterExpressionRestrictions: [ { Property: plannedBusinessTimestampUTC, AllowedExpressions: #SingleInterval, }, { Property: actualBusinessTimestampUTC, AllowedExpressions: #SingleInterval, } ], UI.HeaderInfo: { TypeName: 'Event', TypeNamePlural: 'Events', Title: {Value: to_eventCode.Text}, }, UI.Identification: [ {Value: eventType}, ], UI.SelectionFields: [ eventType, eventStatus ], Capabilities: { Insertable: false, Updatable: false, Deletable: false, FilterRestrictions: { NonFilterableProperties: [ locationlocationId, // FIXME: use association only plannedTechnicalTimestampUTC, plannedBusinessTimestampUTC, actualTechnicalTimestampUTC, actualBusinessTimestampUTC, processingTimestampUTC, ] }, SortRestrictions: { NonSortableProperties: [ locationlocationId, // FIXME: use association only ] }, SearchRestrictions: { Searchable: false },


},) { // Element-level Annotations process @Common.FieldControl:#Hidden @odata.navigable:false; //> I think we need to keep that --> should check later processEventDirectoryId @Common.FieldControl:#Hidden; event @Common.FieldControl:#Hidden; sequence @Common.FieldControl:#Hidden; eventCode @title:'Event' @readonly; eventStatus @Common.FieldControl:#ReadOnly @ValueList:{type:#fixed, entity:'EventStatus'}; @Common.Text: plannedBusinessTimestampUTC_text @Common.TextArrangement: #TextOnly plannedBusinessTimestampUTC; // plannedBizTsEarliestUTC @Common.FieldControl:#Hidden; // plannedBizTsLatestUTC @Common.FieldControl:#Hidden; plannedBusinessTimeZone @Common.FieldControl:#Hidden; @Common.Text: actualBusinessTimestampUTC_text @Common.TextArrangement: #TextOnly actualBusinessTimestampUTC; actualBusinessTimeZone @Common.FieldControl:#Hidden; actualBusinessTimestamp @Common.FieldControl:#Hidden; // Note: in addition, @title is inherited for all from data model};// Line Items for Listsannotate CoreServices.TrackedProcessService.ProcessEventDirectory with @( UI.PresentationVariant: { Visualizations: [ '@UI.LineItem#GenericEvents' ], SortOrder: [ {Property: sequence, Descending: false} ], RequestAtLeast: [ sequence, eventType, to_eventCode.Text, to_eventStatus.EditEnabled, location.description, event.id, event.locationDescription, actualBusinessTimestamp, actualBusinessTimeZonetimeZoneCode, ], }, UI.LineItem: [ {Value: eventCode}, {Value: eventStatus, Criticality: to_eventStatus.Criticality, CriticalityRepresentation: #WithIcon}, {Value: eventReasonText}, {Value: location}, {Value: plannedBusinessTimestampUTC}, {Value: actualBusinessTimestampUTC}, ], UI.LineItem#GenericEvents: [ {Value: eventCode}, {Value: eventStatus, Criticality: to_eventStatus.Criticality, CriticalityRepresentation: #WithIcon}, {Value: eventReasonText}, {Value: location}, {Value: plannedBusinessTimestampUTC}, {Value: actualBusinessTimestampUTC}, {Value: CreatedByUser}, {Value: processingTimestampUTC}, ]);// Facets for Object Pageannotate CoreServices.TrackedProcessService.ProcessEventDirectory with @(



UI.HeaderFacets: [ {$Type: 'UI.ReferenceFacet', Target: '@UI.DataPoint#EventStatus'}, ], UI.DataPoint#EventStatus: { Value: eventStatus, Title: 'Event Status', Criticality: to_eventStatus.Criticality, }, UI.Facets: [ { $Type: 'UI.CollectionFacet', ID: 'DetailInfo', Label: 'Detailed Information', Facets: [ {$Type: 'UI.ReferenceFacet', Target: '@UI.FieldGroup#GeneralInfo'}, {$Type: 'UI.ReferenceFacet', Target: '@UI.FieldGroup#TimeInfo'}, ] }, ], UI.FieldGroup#GeneralInfo: { Label: 'General', Data: [ {Value: location}, {Value: eventReasonText}, ] }, UI.FieldGroup#TimeInfo: { Label: 'Time', Data: [ {Value: plannedBusinessTimestampUTC}, {Value: plannedTechnicalTimestampUTC}, ] });//////////////////////////////////////////////////////////////////////////////// Annotations for BusinessPartner//// @title: 'Business Partners'annotate CoreServices.TrackedProcessService.BusinessPartner with @( UI.Identification: [ {Value: organizationName1}, {Value: streetName}, {Value: postalCode}, {Value: landlinePhoneNumber}, ], //> Collection of UI.DataField w/ PropertyValue Communication.Contact: { fn: organizationName1, adr: [{ label: 'Address', street: streetName, locality: cityName, region: regionDescription, country: countryDescription, code: postalCode, }], tel: [{ type: #work, uri: landlinePhoneNumber, }, { type: #cell, uri: mobilePhoneNumber, }], email: [{ type: #work, address: emailAddress, }], //url: [{


// type: #work, // uri: Website, //}], }, Communication.Address: { label: 'Address', street: streetName, locality: cityName, region: regionDescription, country: countryDescription, code: postalCode, },) { businessPartnerID @title:'ID' @Common: { FieldControl: #Hidden, Text: organizationName1, TextArrangement: #TextOnly }; organizationName1 @title:'Name'; organizationName2 @Common.FieldControl:#Hidden; emailAddress @title: 'Email' @Common.FieldControl:#Hidden; landlinePhoneNumber @title: 'Phone'; mobilePhoneNumber @title: 'Mobile'; houseNumber @title:'House Number'; streetName @title:'Street'; cityName @title:'City'; region @Common.FieldControl:#Hidden; regionDescription @title:'Region'; country @Common.FieldControl:#Hidden; countryDescription @title:'Country'; postalCode @title:'Postal Code'; longitude @title:'Longitude' @Common.FieldControl:#Hidden; latitude @title:'Latitude' @Common.FieldControl:#Hidden; objectGroup @Common.FieldControl:#Hidden;};//////////////////////////////////////////////////////////////////////////////// Annotations for Location//// @title: 'Locations'annotate CoreServices.TrackedProcessService.Location with @( UI.Identification: [ {Value: description}, {Value: locationId}, ], //> Collection of UI.DataField w/ PropertyValue Communication.Contact: { fn: description, }, /*Communication.Address: { label: 'Address', street: LocationData_streetName, locality: LocationData_cityName, region: LocationData_regionDescription, country: LocationData_countryDescription, code: LocationData_postalCode, }*/ ) { locationId @Common.FieldControl:#Hidden @Common:{Text: description, TextArrangement: #TextOnly}; description @title: 'Description';};annotate CoreServices.TrackedProcessService.QualifiedTrackingId with { trackedProcess @odata.navigable:false;};annotate CoreModel.EventCode with @ValueList: {type: #fixed, entity: 'EventDescription'};//////////////////////////////////////////////////////////////////////////////



// Annotations for HierarchyNode//annotate CoreServices.TrackedProcessService.HierarchyNode with @( Capabilities: { Insertable: false, Updatable: false, Deletable: false, SearchRestrictions: { Searchable: false }, },) { // Element-level Annotations process @Common.FieldControl:#Hidden; parent @Common.FieldControl:#Hidden; hierarchyLevel @Common.FieldControl:#Hidden; drillState @Common.FieldControl:#Hidden; validFrom @Common.FieldControl:#Hidden; validTo @Common.FieldControl:#Hidden;};// Line Items for Listsannotate CoreServices.TrackedProcessService.HierarchyNode with @( UI.LineItem: [ {Value: node}, ] );

CoreTypes.cds

namespace sap.appcore.cs.i; context CoreTypes { type Uuid : String(50); type Name : String(255); type Description : String(255); //Description, usually in language depenant "text" tables // business partner and location types /*--type Geolocation : hana.ST_GEOMETRY(4326); **/ type LocationID : Uuid; type BusinessPartnerID : Uuid; type Boolean : Integer; // 0 = false, 1 = true // Tenant field to be used in all transaction and master data tables // Check table: sap.appcore.cs.p::Tenant type Tenant : String(36); type TenantStatus : String(1); // ISO-2 language code to be used in all language dependent tables // Check table: sap.appcore.cs.p::Language type Language : String(2); // user admin data to be used in all tables where audit trail information is required type SystemAdminData { CreatedByUser : String(64); CreationDateTime : Timestamp; LastChangedByUser : String(64); LastChangeDateTime : Timestamp; }; };

CoreAnnotations.cds

annotation title : String; annotation important : Boolean;annotation Criticality : UI.CriticalityType;annotation EditEnabled : Boolean;context odata { annotation entitySet : String; annotation foreignKey : String; annotation foreignKey4 : String; annotation navigable : Boolean;


};type PropertyPath : String;type AnnotationPath : String;// property valuecontext PropertyValue { annotation source : String; // full qualified name of the source entity, or property name of the source association annotation sourceType : String enum { Entity = 'Entity'; Association = 'Association'; }; annotation outSourceProperty : String; // output property in source annotation parameters : array of { inSourceProperty : String; // input property in source localDataProperty : String; // input property in this entity };};// Time Zonecontext TimeZoneInfo { annotation TimeZone : PropertyPath; context toLocalString { annotation UTCTimestamp : PropertyPath; annotation TimeZone : PropertyPath; }; context toLocalTime { annotation UTCTimestamp : PropertyPath; annotation TimeZone : PropertyPath; };};// UI extensioncontext UIExt { context GeoMap { annotation FacetID : String; }; context Hierarchy { annotation FacetID : String; };};// SAP Annotations for OData Version 2.0// See: https://wiki.scn.sap.com/wiki/display/EmTech/SAP+Annotations+for+OData+Version+2.0// ----------------------------------------------------------------------context sap { context semantics { annotation UnitOfMeasure : Boolean; annotation TimeZone : Boolean; }; context applicable { annotation path : String; };};// Org.OData.Core.V1// ----------------------------------------------------------------------context Core { annotation Immutable : Boolean;};// Org.OData.Measures.V1// ----------------------------------------------------------------------context Measures { annotation Unit : String;};// Org.OData.Capabilities.V1// ----------------------------------------------------------------------context Capabilities { annotation FilterRestrictions : FilterRestrictionsType; type FilterRestrictionsType { NonFilterableProperties : array of PropertyPath; };



annotation SortRestrictions : SortRestrictionsType; type SortRestrictionsType { NonSortableProperties : array of PropertyPath; }; annotation SearchRestrictions : SearchRestrictionsType; type SearchRestrictionsType { Searchable : Boolean; }; annotation InsertRestrictions : InsertRestrictionsType; type InsertRestrictionsType { Insertable : Boolean; }; annotation UpdateRestrictions : UpdateRestrictionsType; type UpdateRestrictionsType { Updatable : Boolean; }; annotation DeleteRestrictions : DeleteRestrictionsType; type DeleteRestrictionsType { Deletable : Boolean; };};// com.sap.vocabularies.Common.v1// ----------------------------------------------------------------------context Common { annotation Label : String; annotation Text : String; annotation SemanticObject : String; annotation FilterExpressionRestrictions : array of FilterExpressionRestrictionType; type FilterExpressionRestrictionType { Property : PropertyPath; AllowedExpressions : FilterExpressionType; }; type FilterExpressionType : String enum { SingleValue = 'SingleValue'; MultiValue = 'MultiValue'; SingleInterval = 'SingleInterval'; }; annotation FieldControl : FieldControlType; type FieldControlType : Integer enum { Mandatory = 7; Optional = 3; ReadOnly = 1; Inapplicable = 0; Hidden = 0; }; annotation ValueList : ValueListType; type ValueListType { Label : String; CollectionPath : String not null; SearchSupported : Boolean; Parameters : array of ValueListParameter; }; annotation ValueListWithFixedValues : Boolean; type ValueListParameter { $Type : String enum { ValueListParameterInOut = 'Common.ValueListParameterInOut'; ValueListParameterIn = 'Common.ValueListParameterIn'; ValueListParameterOut = 'Common.ValueListParameterOut'; ValueListParameterDisplayOnly = 'Common.ValueListParameterDisplayOnly'; ValueListParameterFilterOnly = 'Common.ValueListParameterFilterOnly'; }; ValueListProperty : String; }; type ValueListParameterIn : ValueListParameter { LocalDataProperty : PropertyPath; }; type ValueListParameterInOut : ValueListParameter {


LocalDataProperty : PropertyPath; }; type ValueListParameterOut : ValueListParameter { LocalDataProperty : PropertyPath; }; type ValueListParameterDisplayOnly : ValueListParameter; type ValueListParameterFilterOnly : ValueListParameter; annotation SemanticKey : array of PropertyPath; annotation SortOrder : array of SortOrderType; type SortOrderType { Property : PropertyPath; Descending : Boolean; };};// com.sap.vocabularies.Communication.v1// ----------------------------------------------------------------------context Communication { annotation Contact : ContactType; type ContactType { fn : String; adr : array of AddressType; tel : array of PhoneNumberType; email : array of EmailAddressType; }; annotation Address : AddressType; type AddressType { street : String; locality : String; region : String; code : String; country : String; label : String; type : ContactInformationType; }; type PhoneNumberType { uri : String; type : PhoneType; }; type EmailAddressType { address : String; type : ContactInformationType; }; type ContactInformationType : Integer enum { work = 1; home = 2; preferred = 4; }; type PhoneType : Integer enum { work = 1; home = 2; preferred = 4; voice = 8; cell = 16; fax = 32; video = 64; };};// com.sap.vocabularies.UI.v1// ----------------------------------------------------------------------context UI { type DataFieldAbstract : { $Type : String enum { DataField = 'UI.DataField'; DataFieldForAnnotation = 'UI.DataFieldForAnnotation'; DataFieldForAction = 'UI.DataFieldForAction'; DataFieldForIntentBasedNavigation = 'UI.DataFieldForIntentBasedNavigation'; DataFieldWithAction = 'UI.DataFieldWithAction';



DataFieldWithIntentBasedNavigation = 'UI.DataFieldWithIntentBasedNavigation'; DataFieldWithNavigationPath = 'UI.DataFieldWithNavigationPath'; DataFieldWithUrl = 'UI.DataFieldWithUrl'; }; Label : String; Criticality : CriticalityType; CriticalityRepresentation : CriticalityRepresentationType; }; type CriticalityType : Integer enum { Neutral = 0; Negative = 1; Critical = 2; Positive = 3; }; type CriticalityRepresentationType : String enum { WithIcon = 'WithIcon'; WithoutIcon = 'WithoutIcon'; }; annotation TextArrangement : TextArrangementType; type TextArrangementType : String enum { TextFirst = 'TextFirst'; TextLast = 'TextLast'; TextSeparate = 'TextSeparate'; TextOnly = 'TextOnly'; }; annotation Importance : ImportanceType; type ImportanceType : String enum { High = 'High'; Medium = 'Medium'; Low = 'Low'; }; type DataField : DataFieldAbstract { Value : PropertyPath; }; type DataFieldForAnnotation : DataFieldAbstract { Target : AnnotationPath; }; type DataFieldWithUrl : DataField { Url : String; }; annotation HeaderInfo : HeaderInfoType; type HeaderInfoType { TypeName : String not null; TypeNamePlural : String not null; Title : DataField not null; Description : DataField; }; annotation Identification : array of DataFieldAbstract; annotation LineItem : array of DataFieldAbstract; annotation SelectionFields : array of PropertyPath; annotation FieldGroup : FieldGroupType; type FieldGroupType { ID : String; Label : String; Data : array of DataFieldAbstract; }; annotation DataPoint : DataPointType; type DataPointType { Title : String; Description : String; Value : PropertyPath; Criticality : CriticalityType; }; annotation Facets : array of Facet; annotation HeaderFacets : array of Facet; type Facet { $Type : String enum {


ReferenceFacet = 'UI.ReferenceFacet'; CollectionFacet = 'UI.CollectionFacet'; }; ID : String; Label : String; }; type CollectionFacet : Facet { Facets : array of Facet; }; type ReferenceFacet : Facet { Target : AnnotationPath; }; annotation PresentationVariant : PresentationVariantType; type PresentationVariantType { ID : String; SortOrder : array of Common.SortOrderType; Visualizations : array of AnnotationPath; RequestAtLeast : array of PropertyPath; };};// SAP EM// ----------------------------------------------------------------------context SAP_EM { annotation applicationObjectType : String; // data element /SAPTRX/AOTYPE context eventCode { annotation Code : String; annotation Text : String; annotation Type : String; }; annotation fieldName : String; // data element /SAPTRX/PARAMNAME annotation itemized : Boolean; // indicates that this particular entity covers items annotation itemizedEntity : String; // refers to another entity that handles items annotation primaryTrackingIdType : String; // data element /SAPTRX/TRXCOD};// SAP DPP// ----------------------------------------------------------------------context DPP { annotation PII : Boolean; annotation SPI : Boolean; annotation DataSubjectID : Boolean; };

5.2.2.1 Core Model Data Types

This chapter describes the scalar and complex data types and entities the core model provides.

Scalar Data Types

Table 11:

Type Technical Type Description

LocationId UUID UUID of a location




ExternalLocationIdType String(50) The identifier type, for example, type “geo location” or type “ERP Shipping Point” of the following external location ID. There is no fixed set of types.

ExternalLocationId String(40) The external identifier of the location

UnitOfMeasure String(6) Unit of measure

TimeZoneCode String(50) Code of the time zone according to JAVA convention

ValidityStartTimestampUTC Timestamp A timestamp that denotes the beginning of a validity period

ValidityEndTimestampUTC Timestamp A timestamp that denotes the end of a validity period

LogicalSenderSystem String(10) A value that identifies a logical system from a party that sends data to track and trace. This could be for example the logical system value of the table T000 in an ABAP based sender system.

TrackedProcessId UUID The UUID of a tracked process instance

TrackedProcessType String(255) The (human readable) type of a tracked process, for example, com.sap.gtt.app.deliverysample.DeliveryProcess

EventId UUID The UUID of an actual event

EventCode String(255) The (human readable) type of an event, for example, com.sap.gtt.app.deliverysample.GoodsIssued

EventSequence Integer The sequence of the event

TrackingId String(50) The external ID value of an tracking ID (see Qualified Tracking ID in Helper Entities)

TrackingIdType String(40) The type of the tracking ID, for example, a delivery id

EventReasonText String(255) A free text that describes the event reason for a manually created event


Complex Data Types

Table 12:

Complex Type Description

EventQualifiedTrackingId The quadruple of sender, logical system ID, tracking ID type, and tracking ID.

See Qualified Tracking ID in Helper Entities for details.

5.2.2.2 Helper Entities

Helper entities are those entities that are not tracked processes or events, but required to be modeled as an entity in an ERM.

Location

This entity describes the location where an event happened with an internal ID, an external ID, and a text description.

Table 13:

Attribute Technical Type Description

id (key) UUID The UUID of the location

sender Association The business partner (owner) of the external location ID

logicalSenderSystem LogicalSenderSystem The ID owner’s system of origin of the external location ID

locationIdType ExternalLocationIdType The type of the external location ID defined by the sender

locationId ExternalLocationId The external location ID

description Description A free text description of the location

Time Zone

The time zone entity. Main use case is a value help on the UI.



Table 14:


timeZoneCode (key) TimeZoneCode The time zone in Java notation

description Description A textual description of the time zone. In Java, code and description are identical.

Qualified Tracking ID

The tracking ID is not a simple value but consists of a quadruple of sender, logical system, ID type and the ID itself. This entity is used to assign this quadruple together with a validity period to a tracked process. The tracking ID that uniquely identifies the tracked process is the primary ID.

NoteOften we do not distinguish between the qualified tracking ID (quadruple) and the tracking ID (scalar value), but in most cases we mean by “tracking ID” actually the “qualified tracking ID”.

Table 15:


trackedProcess (key) Association The tracked process to which the tracking ID belongs

sender (key) Description The business partner (owner) of the tracking ID

logicalSenderSystem (key) LogicalSenderSystem The ID owner’s system of origin of the tracking ID

trackingIdType (key) TrackingIdType The type of the tracking ID defined by the sender

trackingId (key) TrackingId The tracking ID itself

validFromUTC ValidityStartTimestampUTC The start time stamp of the period in which the qualified tracking ID is valid for the process

validToUTC ValidityEndTimestampUTC The end time stamp of the period in which the qualified tracking ID is valid for the process



primaryId Boolean True if the tracking ID uniquely identifies the tracked process. This value is defined by the first sender of the tracked process. The validity period has no meaning if this flag is set.

Event Status

The event status is a helper entity to allow value help in user interfaces and assign properties to an event status that can be used in reporting.

Table 16:


Code (key) String(10) The event code

Text String(50) A textual UI relevant description of the event code

Criticality Integer16 Defines the criticality of the event status

EditEnabled Boolean True if the even status can be changed

5.2.2.3 Main Entities

Tracked Process

Tracked process is the heart of the SAP Global Track and Trace solution. The abstract tracked process entity as defined in the core model provides all attributes and associations that are necessary to track a process.

Table 17:


id (key) TrackedProcessId The UUID of the tracked process

tenant Tenant The tenant to which the tracked process instance belongs




name Name A natural language text to name the tracked process instance

description Description A natural language text to describe the tracked process instance

trackedProcessType TrackedProcessType The type of the tracked process instance

trackingIds Composition The set of qualified tracking IDs to retrieve the tracked process during event processing

processEvents Association The process event directory for the tracked process instance

lastProcessEvent Association For convenience during processing the pointer to the last processed event

CreatedByUser systemAdminData The administrative data to audit the creation of a tracked process instance

CreationDateTime Timestamp The administrative data to audit the creation of a tracked process instance

LastChangedByUser String(64) The administrative data to audit the change of a tracked process instance

LastChangeDateTime Timestamp The administrative data to audit the change of a tracked process instance

Event

Event represents any kind of business event that occurred.

NoteThere are two “sender” fields: The sender of the event message and the sender in sense of an owner of the tracking ID. For example: A carrier sends an event for a delivery of a supplier. The sender of the event is the carrier, the sender of the ID is the supplier.

Table 18:


id (key) EventId The UUID of the event



tenant Tenant The tenant to which the event belongs

eventCode EventCode The (human readable) event code

eventType String(255) The (human readable) event type

senderParty Association The business partner who has sent the event

logicalSenderSystem LogicalSenderSystem The logical sender system of qualified tracking ID as quadruple (sender, logical sender system, tracking ID type, tracking ID)

trackingIdType TrackingIdType The tracking ID type of qualified tracking ID

trackingId TrackingId The tracking ID of qualified tracking ID

actualTechnicalTimestampUTC Timestamp The time stamp when the event has been received by the system

actualBusinessTimestampUTC Timestamp The time stamp when the event actually has happened

actualBusinessTimezone Association The time zone of the time stamp above

location Association The location where the event actually has happened

CreatedByUser String(64) The user name who has created the event. Either a technical user in case that the event is reported via ingestion pipeline or a real user name in case the event was reported from the UI.

Process Event Directory

The process event directory is the link between tracked processes and events and serves two purposes:

1. List the planned events of the tracked process with plan data. Link to an actual event once the event has happened.

2. List all unplanned events (plan data will be empty in this case) that have happened to the tracked process.

From a business perspective, planned and unplanned events should be covered together in one common list.



Table 19:


process (key) Association The tracked process to which the process event directory entry belongs

processEventDirectoryId (key) UUID The unique ID of the process event directory entry

tenant Tenant The tenant to which the entry belongs

eventCode EventCode The event code of the event

eventStatus EventStatus The status of the event

eventReasonText EventReasonText A free text to describe the reason for a manually created event

event Association The event to which the process event directory entry belongs

sequence EventSequence The sequence of event directory

location Association The location of event directory

plannedTechnicalTimestampUTC Timestamp The planned point in time by when the event shall be reported from technical perspective

plannedTechTsEarliestUTC Timestamp The earliest point in time by when the event may be reported from technical perspective

plannedTechTsLatestUTC Timestamp The latest point in time by when the event must have been reported from technical perspective

plannedBusinessTimestampUTC Timestamp The planned point in time by when the event shall happen from business perspective

plannedBizTsEarliestUTC Timestamp The earliest point in time by when the event may happen from business perspective

plannedBizTsLatestUTC Timestamp The latest point in time by when the event must have happened from business perspective

plannedBusinessTimeZone Association The time zone of the three points in time above



actualTechnicalTimestampUTC Timestamp The actual point in time by when the event shall be reported from technical perspective

actualBusinessTimestampUTC Timestamp The actual point in time by when the event shall happen from business perspective

actualBusinessTimeZone Timestamp The time zone of the point in time above

CreatedByUser String(64) The name of the user who has created the event. It can be either a technical user in case that the event is reported via ingestion pipeline or a real user name in case the event was reported from the UI.

processingTimestampUTC Timestamp The time when the event is created.

5.2.2.4 Annotations

Annotations are a powerful concept within CDS to extend a metadata model definition with additional metadata to control behavior of consumers of the metadata model. The core model defines the following annotations that are used by the core engine.

In principle, each CDS element can be annotated. However annotations fulfill a certain purpose and hence can only be used for certain elements defined by annotations scope.



Table 20:

Annotation Scope Technical Type Description

ObjectIdentifierType Attribute String(255) Describes for an external ID what the ID originally described. Used in context of inbound processing for messages coming from an SAP ERP system.

Admissible values for business partner are:

● customer● vendor● businessPartner● others

Admissible values for location are:

● customerLocation● vendorLocation● businessPartner● shippingPoint● plant

If location is needed in events and event messages, this annotation must be defined on location of event, for example, annotate DelayedEvent with {

location @CoreModel.ObjectIdentifierType: #customerLocation;

};

UsageType Entity String(255) Describes the main purpose of an entity:

● inboundMessage● userInterface● search● searchResult

MainEntity Entity Boolean Defines the main entity of a service definition that is shown as separate tile in the Fiori Launchpad emulation.



BaseType Entity String(255) Describes the base type of an entity:

● TrackedProcess● BusinessPartner● Location

SAP_EM The set of annotations within SAP_EM that refers to the integration of SAP Global Track and Trace with SAP Event Management.

.primaryTrackingIdType Entity String(20) The type of the primary tracking ID as passed from SAP Event Management. If this annotation is not set, the application Object Type is used as primary Tracking ID Type. There must be only one entity annotated with the same primary Tracking ID Type within one tenant.

.applicationObjectType Entity String(20) Creates the link between a track and trace entity (tracked process) and the application object type received from SAP Event Management. There must be only one entity annotated with the same application object name that is not itemized within one tenant.

.fieldName Attribute String(32) Defines for an attribute from which parameter in the message the attribute is filled.

.eventCode Entity String(20) Creates the link between an SAP EM event code and the event entity. Note that the event code must be unique within one tenant.




.itemized Entity Boolean Indicates whether the entity is itemized. In this case, the indexed parameters of the SAP EM message are evaluated and each set with same index will map into the same instance.

.itemizedEntity Attribute String(255) Defines for an attribute of an entity that this attribute is not a scalar value but an association which might be contained in the message payload as well. This eases to find from the entity all itemized sub-entities like the delivery items of a delivery.

KeepStatusSequence Attribute Boolean A status field of an entity might be associated with ‘true’. In this case, an event does only change the status field when the new status is logically after the old status. For example: A delivery is picked, issued and completed. If for technical reasons the picking event is being reported after the proof of delivery, the status “delivered” remains.

UpdateStatus Entity Array of An array of new status values that are set when an event happens. The ingestion checks for each affected tracked process whether the given type matches and the status attribute exists and sets the status new under consideration of the order.

.pathToStatus String(255) The full path (entity type name + status attribute) of the status to be updated.

.newValue String(255) The new status value.



StatusProperties Entity Array of String(255) The status fields of an entity. These must not be set by any message call other than event inbound processing.

Planned Events Entity Array of The initial list of planned events once the tracked process is being instantiated. Each entry consists of four fields.

.eventCode EventCode The event code of the planned event. Note that the event code must be unique within one tenant.

.matchLocation Boolean An indicator whether an actual event matches the planned event only in case when the locations match as well.

.technicalToleranceValue Timestamp A tolerance window that defines a time window around the planned technical time stamp in which the actual event is considered to be “not a delay.” This value is given as time stamp period presentation like P[JY][MM][WW][TD][T[hH][mM][s[.f]S]] according to ISO 8601.

.businessToleranceValue Timestamp A tolerance window that defines a time window around the planned business time stamp in which the actual event is considered to be “not a delay.” This value is given as time stamp period presentation like P[JY][MM][WW][TD][T[hH][mM][s[.f]S]] according to ISO 8601.




AdmissibleUnplannedEvents Entity Array of EventCode A list of admissible unplanned events, i.e. events that are allowed to be reported manually and that can be handled somehow in the tracked process.

DPP Marks an attribute as relevant to Data Protection and Privacy.

Notes:

● DPP annotations can only be used on header-level attributes of the tracked process entity. Otherwise an error will occur when the model is compiled.

● Once a model with DPP annotations is deployed, you cannot remove the existing DPP annotations and redeploy the model.

.PII Attribute Boolean Marks an attribute as Personally Identifiable Information, also known as personal data. The personal data change log includes all attributes marked with this annotation.

.SPI Attribute Boolean Marks an attribute as Sensitive Personal Information, also known as sensitive personal data. The personal data change log and read access log include all attributes marked with this annotation.



.DataSubjectID Attribute Boolean Marks an attribute as the data subject ID.

Notes:

● @DPP.DataSubjectID can only be used on an attribute that is an email address.

● An attribute annotated with @DPP.DataSubjectID must also be annotated with @DPP.PII.

● If @DPP.PII or @DPP.SPI is used in a model, the model must have one and only one @DPP.DataSubjectID.

5.2.2.5 Core Model Service

The core model service exposes the following entities and can be extended by applications. For all entities any kind of tenant information is being excluded.

● Event● ProcessEventDirectory

The location ID of planned location is included.With additional action EditEvent

● QualifiedTrackingId● BusinessPartner● Location● TimeZone● EventStatus● TrackedProcess

With additional action ReportUnplannedEvent

5.2.3 UI Annotations

To be able to use SAP Fiori Elements as generic UI to display tracked processes and events, a special set of annotations is required to control the UI layout.



NoteMore about SAP Fiori Elements can be found at https://experience.sap.com/fiori-design-web/smart-templates/ .

In the following we provide the subset of SAP Fiori Elements annotations that are currently supported for SAP Global Track and Trace.

As shown in the Overall Structure section, we have annotations for the core engine and for applications leveraging the core engine. Both are mixed together during runtime.

Related Information

Overall Structure [page 43]

5.2.3.1 UI Structure

For each tracked process type defined in applications we use overview pages and object pages of SAP Fiori Elements. The overview page shows a list of all tracked processes with filter capabilities, and the object page shows the details of one tracked process instance with a list of events.

The following shows an example of the overview page.

The following shows an example of the object page.


http://help.sap.com/disclaimer?site=https://experience.sap.com/fiori-design-web/smart-templates/

http://help.sap.com/disclaimer?site=https://experience.sap.com/fiori-design-web/smart-templates/

5.2.3.2 Overview Page

Annotations on Tracked Process Types

To get the overview page rendered we have to use the following annotations for the tracked process type. As we annotate in a separate file than the service definition, we use the following CDS syntax to define the UI layout.

annotate <TrackedProcess> with @( <annotations> )

The following annotations are allowed:

CommonThe common block defines overall behavior for the overview page and contains the following attributes:

● Common.LabelDefines the label for the overview page, for example, a natural language term for the tracked processes like “Delivery”.CDS Annotation Definition:

Common: { Label: 'Delivery'}

● Common.SemanticKeyAn array of field names as defined in the annotated service that describe the semantic key of the tracked process (for example: ‘deliveryId’).CDS Annotation Definition:

Common: { SemanticKey: [ deliveryId, ]}

These fields will be rendered as bold style in the list report table.


● Common. FilterExpressionRestrictionsAn array of tuples with two fields:○ Property○ AllowedExpressions

Where Property denotes a field name as defined in the annotated service and AllowedExpressions defines how a filter can be entered. SAP Global Track and Trace currently allows only the value #SingleInterval for date type fields.CDS Annotation Definition:

Common: { FilterExpressionRestrictions: [ { Property: deliveryDate, AllowedExpressions: #SingleInterval, }, { Property: loadingDate, AllowedExpressions: #SingleInterval, }, { Property: transPlanDate, AllowedExpressions: #SingleInterval, } ],}

UIThe UI block defines how the overview page looks like. The following attributes are allowed:

● UI.IdentificationList of field names as defined in the annotated service that uniquely identify the tracked object. Usually this is the same list as specified for Common.SemanticKey.CDS Annotation Definition:

UI: { Identification: [ deliveryId, ]}

● UI.HeaderInfoDefines how the header of the overview page looks like. The following attributes are possible.CDS Annotation Definition:

UI { HeaderInfo: { TypeName: 'Delivery', TypeNamePlural: 'Deliveries', Title: { Label: 'Outbound Delivery', Value: deliveryId }, Description: {



Label: 'Track Outbound Delivery', Value: description } }}

● UI.HeaderInfo.TypeNameThe name of the tracked process type in singular form (for example: “Delivery””)

● UI.HeaderInfo.TypeNamePluralThe name of the tracked process type in plural form (for example: “Deliveries”)

● UI.HeaderInfo.TitleA tuple of Label and Value that defines the title of the object page for one particular tracked process instance.

● UI.HeaderInfo.DescriptionA tuple of Label and Value that defines the description of the object page for one particular tracked process instance. The description is rendered beside the title.

● UI.SelectionFieldsA list of field names as defined in the annotated service that are initially visible in the filters bar.CDS Annotation Definition:

UI { SelectionFields: [ deliveryId, sender, salesOrganization, deliveryDate, deliveryStatus, shippingStatus ]}


● UI.PresentationVariantDefines how the result is displayed in the table. Currently SAP Global Track and Trace only allows SortOrder, which is a list of sort criteria for the default sorting.CDS Annotation Definition:

UI { PresentationVariant: { SortOrder: [ {$Record: [ {$PropertyValue: {Property: 'Property', PropertyPath: 'deliveryId'}}, {$PropertyValue: {Property: 'Descending', Bool: true}} ]}, {$Record: [ {$PropertyValue: {Property: 'Property', PropertyPath: 'deliveryDate'}}, {$PropertyValue: {Property: 'Descending', Bool: true}} ]} ] }}

The above example defines the initial sorting by 'deliveryId' and 'deliveryDate` properties in descending order.

Capabilities

The capabilities section defines overall behavior of the application. It may contain the following attributes:

● Capablities.InsertableCapablities.UpdateableCapablities.DeleteableThese properties define whether an instance can be inserted, updated or deleted from the UI. For SAP Global Track and Trace these values must be false.CDS Annotation Definition:

Capabilities: { Insertable: false, Updatable: false, Deletable: false,}

● Capabilities.FilterRestrictions



Defines restrictions on the filter capabilities of the overview list. Currently SAP Global Track and Trace only allows NonFilterableProperties, which is a list of field names as defined in the annotated service that cannot be used as filter criteria.CDS Annotation Definition:

Capabilities: { FilterRestrictions: { NonFilterableProperties: [ description, sender, shipToParty, soldToParty, shippingPoint, to_shippingType, to_deliveryStatus, to_shippingStatus, deliveryWeightUnit, deliveryVolumeUnit, ] }}

● Capabilities.SortRestrictionsDefines restrictions on the sort capabilities of the overview list. Currently SAP Global Track and Trace only allows NonSortableProperties, which is a list of field names as defined in the annotated service that cannot be used as sort criteria.CDS Annotation Definition:

Capabilities: { SortRestrictions: { NonSortableProperties: [ ] }}

● Capabilities.SearchRestrcitionsDefines the search restrictions. Currently SAP Global Track and Trace does not allow any search capabilities beside filtering, hence the only admissible property Searchable must be set to false.CDS Annotation Definition:

Capabilities: { SearchRestrictions: { Searchable: false }}

Annotations on Fields

Some fields shall be rendered in the UI in a different way that is defined by annotations. As we annotate in a separate file than the service definition, we use the following CDS syntax to define the UI layout.

annotate <TrackedProcessUI> with { <field annotations> }

For fields, the following annotations are allowed:

● TitleDefines the label for a certain field.


CDS Annotation Definition:

annotate Delivery with: { deliveryId @title: 'Delivery ID'; description @title: 'Description';}

● Common.FieldControlDefines the appearance of the field on the UI. Currently the only supported value is #Hidden.CDS Annotation Definition:

annotate Delivery with: { id @Common.FieldControl: #Hidden;}

● ValueListDescribes how a value help for a particular field is being created. It is a tuple of type and entity.The type describes the type of the value list. For SAP Global Track and Trace, only #fixed is allowed. The entity names the entity that provides a value list. To query data to display the value help, the UI will request data from that entity via OData call.CDS Annotation Definition:

annotate Delivery with: { deliveryStatus @ValueList: { type: #fixed, entity: 'DeliveryStatus' };}

Annotations for Line Items

The overview page contains a list of all tracked processes that match the given filter criteria. The appearance of the list needs to be defined with annotations as well.

For that, we annotate the tracked process type with a set of fields to appear in the list. We use the following CDS syntax for this kind of annotation.

annotate <TrackedProcessUI> with @UI.LineItem: [ <set of fields> ]


annotate Delivery with @UI.LineItem: [ deliveryId, sender,



salesOrderId, purchaseOrderId, shipToParty, salesOrganization, deliveryDate, loadingDate, { Value: deliveryStatus, Criticality: to_deliveryStatus.Criticality, CriticalityRepresentation: #WithoutIcon }, shippingStatus,];

<set of fields> is an array of the following structure:

● ValueIs the field name as defined in the annotated service that shall appear in the list. This property is mandatory and default if no property name is given.

● CriticalityDefines how the value is displayed. This value could either be a path to another field or a fixed value 0 (neutral, grey, default), 1 (negative, red), 2 (critical, yellow) or 3 (positive, green). This property is optional.

● CriticalityRepresentationDefines whether an icon shall be used to display critical status or not. Supported values are #WithoutIcon and #WithIcon. This property is optional.

5.2.3.3 Object Page

The object page is defined via facets. A facet contains a set of fields or a list of referenced entities to be displayed. A facet is either described by a field group or by line item annotations of an associated entity.

We use the following CDS syntax to define the faces and field groups.

annotate <TrackedProcessUI> with @( ... )

The object page is structured in facets, whether for header or for the object details. Each facet hereby is a single data point, a field group, or a set of other facets.

Annotations for Facets

UI.HeaderFacetsThis contains all field groups or data points to be displayed in the header of the object page. The annotation is a list of tuples with Type and Target. Type is always 'UI.ReferenceFacet', whereas Target is a reference to the field


group in format '@UI.FieldGroup#<ID>' or data point that defines the data to be show in format '@UI.DataPoint#<ID>'.


// HeaderFacets for Object Page annotate Delivery with @( UI.HeaderFacets: [ { Type:'UI.ReferenceFacet', Target: '@UI.FieldGroup#shippingStatus' }, { Type:'UI.ReferenceFacet', Target: '@UI.DataPoint#deliveryStatus' }, ]}

UI.Facets

Similar to header facets, we can define the structure of the object page.


// Facets for Object Page annotate Delivery with @( UI.Facets: [ { Type: 'UI.CollectionFacet', ID: 'BusinessProcess', Label: 'Business Process', Facets: [ { Type: 'UI.CollectionFacet', ID: 'DetailInfo', Label: 'Detailed Information', Facets: [ { Type: 'UI.ReferenceFacet', Target: '@UI.FieldGroup#Sales' }, { Type: 'UI.ReferenceFacet', Target: '@UI.FieldGroup#Shipping' }, { Type: 'UI.ReferenceFacet', Target: '@UI.FieldGroup#Package' }, ] }, { Type: 'UI.CollectionFacet', ID: 'DeliveryItems', Label: 'Delivery Items', Facets: [ { Type: 'UI.ReferenceFacet', Target: 'items/@UI.LineItem' }, ] }, { Type: 'UI.CollectionFacet', ID: 'Events', Label: 'Event Messages', Facets: [ { Type: 'UI.ReferenceFacet', Target: 'processEvents/@UI.LineItem#GenericEvents' }, ] } ] }



]}

UI.Facets are an array of structure with the following fields and can be nested.

● IDThe unique ID of the facet. This value is mandatory.

● LabelA label for the facet. This value is optional.

● TypeThe type of the facet. If this facet contains sub facets, the type should be 'UI.CollectionFacet', otherwise it is 'UI.ReferenceFacet'.

● TargetA field group or data point that defines the data to be shown in format '@UI.FieldGroup#<ID>' or line items of an associated another entity in form of '<association>/@UI.LineItem#<ID>'.

● FacetsAn array of facets to be included in that facet. Nesting of facets influences how field groups are displayed on the screen. A facet must either contain a Target or another set of Facets.

● UI.FieldGroupAn ordered collection of data fields with a label for the group. It is used to represent parts of a single data instance in a form.CDS Annotation Definition:

UI.FieldGroup#Shipping: { Label: 'Shipping Information', Data: [ shippingType, shippingPoint, transPlanDate, loadingDate, deliveryDate, ]},UI.FieldGroup#Package: { Label: 'Package Details', Data:[ numberOfPackages, deliveryVolume, deliveryWeight, deliveryNetWeight, ]}


● UI.DataPointVisualizes a single point of data. It is used to render a semantic color for a data field.CDS Annotation Definition:

UI.DataPoint#deliveryStatus: { Title: 'Delivery Status', Value: deliveryStatus, Criticality: to_deliveryStatus.Criticality}

Annotations for Line Items

The annotations for line items in the object page are the same as line items on the overview page.


// Line Item for DeliveryItems annotate DeliveryService.DeliveryItem with @UI.LineItem: [ deliveryItem, material, deliveryQty, pickingQty];

You need to reference this UI.LineItem annotation associated another entity in UI.Facets in form of '<association>/@UI.LineItem'.

// Facets for Object Page annotate Delivery with @( UI.Facets: [ { Type: 'UI.CollectionFacet',



ID: 'BusinessProcess', Label: 'Business Process', Facets: [ { Type: 'UI.CollectionFacet', ID: 'DeliveryItems', Label: 'Delivery Items', Facets: [ { Type: 'UI.ReferenceFacet', Target: 'items/@UI.LineItem' }, ] } ] } ])

5.2.4 Delivery Application Details

The delivery application comes with additional metadata model definition that extends the generic tracked process definition with delivery specific fields.

Standard Mode Delivery Application

A standard mode delivery application consists of three files. The details are described in the subsequent topics in this section.

Table 21:


DeliveryModel.cds com.sap.gtt.app.deliverysample

DeliveryModel Defines the metadata model (tracked processes and events) for the delivery application.

DeliveryService.cds com.sap.gtt.app.deliverysample

DeliveryService Exposes the necessary entities as a service.



DeliveryUI.cds com.sap.gtt.app.deliverysample

Not applicable Provides the UI annotations for Fiori Elements of the delivery application.

Simple Mode Delivery Application

A simple mode delivery application only consists of the DeliveryModel.cds file. The metadata model details are similar to those for the standard mode. However, a simple mode delivery application does not have separate service and UI annotation files. The DeliveryModel.cds file for simple mode delivery application also includes some basic service and UI annotations.

The annotations for simple mode delivery application are as follows:

Table 22:


ShowCriticality Attribute Boolean Indicates whether the field are visualized in color.

Semantickey Attribute Boolean Indicates whether the attribute is the semantic key of the tracked process.

SortOrder Entity Defines sort order.

.ByField String Defines which attribute the search result is sorted by.

.Descending Boolean Indicates the search result is sorted in descending order.

SearchFields Entity Defines the fields shown on the Overview page.

.FilterFileds Array of string Defines which fields are initially visible in the Filters bar.

.ResultFileds Array of string Defines which fields are initially visible in the search result table.

LayoutGroups Entity Array of A collection of data fields with a group name and label for each group.




.GroupName String Defines the name of the group.

.Label String Defines the label of the group.

.Data Array of string Defines the data fields contained in the group.

LayoutFacets Entity Array of Defines how the facets are structured in Details page.

.Header Array of string Defines which layout groups are shown in the header area.

.Main Array of string Defines which layout groups are shown in the details area.

.Sublists Array of string Defines which association attributes are shown. This field is optional. A tracked process can contain no sub-list.

SublistFields Entity Array of Defines which fields are visible in the sub-list.

.SublistName Array of string Indicates the sub-list to be configured.

.Data Array of String Defines the data fields contained in the sub-list.

MapEnabled Entity Boolean Indicates whether a Map tab is enabled in the process’ Details page

Map.CurrentProcessLocation Attribute Defines current process location.

.Longitude Boolean Marks this field as the longitude of the current process location.

.Latitude Boolean Marks this field as the latitude of the current process location.

.UpdateTimestamp Boolean Marks this field as the update timestamp for the current process location.


.Data supports three formats:

1. If it is a normal filed, it should be defined similarly with: Data: [filedName]2. If it is shown as a contact card, it should be defined similarly with:

Data: [{Type:'UI.DataFieldForAnnotation', Label:'Label Name', Target: filedName /@Communication.Contact'}

3. If it is shown as a hyperlink, it should be defined similarly with:Data: [{$Type:'UI.DataFieldWithUrl',Target: filedName, URL: '#TrackedProcess-display?model=com.sap.gtt.app.deliverysample&deliveryId={ filedName }' }]

5.2.4.1 Application Specific Data Types

The delivery application defines some application specific data types.

Scalar Data Types

Table 23:


DocumentNumber String(10) The document number of the delivery as defined in SAP ERP system

CustomPONumber String(20) The number of the customer purchase orders as stored in the SAP ERP system

ShippingStatusCode String(50) The shipping status of the delivery as defined in SAP ERP system. Admissible values are:

● notStarted = '01'● pickingCompleted = '02'● goodsIssued = '03'● proofOfDelivery = '04'

DeliveryStatusCode String(2) The delivery status of the delivery as defined in SAP ERP system. Admissible values are:

● onTime = '01'● delayed = '02'




ShippingTypeCode String(20) The shipping type as defined in an ERP system. Admissible values are:

● truck = '01'● mail = '02'● train = '03'● ship = '04'● airplane = '05'● driverUnload = 'DU'● liftgate = 'LG'● ltl = 'LT'● multimodal = 'MM'● nextDayAir = 'P1'● secondDayAir = 'P2'● ground = 'P3'● truckVSWM = 'WM'

5.2.4.2 Helper Entities

Helper entities within the delivery application serve mainly for value lists.

Shipping Status

Table 24:


Code (key) ShippingStatusCode The code of the shipping status

Text String(50) The text of the shipping status

Delivery Status

Table 25:


Code (key) DeliveryStatusCode The code of the delivery status



Text String(50) The text of the delivery status

Criticality Integer16 The criticality of a status value

Shipping Type

Table 26:


Code (key) ShippingTypeCode The code of the shipping type

Text String(50) The text of the shipping type

5.2.4.3 Business Entities

Delivery Items

The delivery application tracks deliveries originated in SAP ERP systems.

Table 27:


delivery (key) Association The delivery process to which the items belong

deliveryItem (key) String(6) The position number of the delivery item

distributionChannel String(255) The distribution channel

plant String(4) The plant

storageLocation Association The location where the item is stored

material String(40) The material code

deliveryQty Decimal(13,2) The quantity to be delivered

pickingQty Decimal(13,2) The picked quantity




deliveryQtyUnit UnitOfMeasure The unit of measure of the two quantities above

5.2.4.4 Tracked Process "Delivery Process"

The delivery process is the major entity of the delivery application. It extends the abstract tracked process as defined in the core engine.

General Data

Entity name: DeliveryProcess

Namespace: com.sap.gtt.app.delivery.sample

Context: Delivery

Type: extends CoreModel.TrackedProcessInstance

Description: The entity is used for data modelling of a delivery process

Attributes

Table 28:


deliveryId DocumentNumber The ID of the delivery document as received from the ERP system of the supplier

salesOrderId DocumentNumber The ID of the corresponding sales order document as received from the supplier’s ERP system

shipToParty Association The business partner who will receive the delivery

soldToParty Association The business partner who will pay for the delivered goods



salesOrganization String(4) Internal sales organization of the supplier

deliveryDate Date The date by when the delivery shall happen

loadingDate Date The date when the delivery is being loaded (for example, handed to the carrier)

transPlanDate Date The date by when the transportation is finished

shippingPoint Association The location where the delivery is shipped to

deliveryWeight Decimal(15,3) The gross weight of the delivery

deliveryNetWeight Decimal(15,3) The net weight of the delivery

deliveryWeightUnit UnitOfMeasure The unit of the above two values

deliveryVolume Decimal(15,3) The volume of the delivery

deliveryVolumeUnit UnitOfMeasure The unit of the above value

shippingType ShippingTypeCode The kind of how the delivery is being shipped

purchaseOrderId CustomerPONumber The ID of the purchase order document of the corresponding ERP system of the customer

numberOfPackages Integer The number of packages of which the delivery consists

DeliveryStatus DeliveryStatusCode The current status of the delivery

ShippingStatus ShippingStatusCode The current status of the shipment

items Association The items of the delivery as separated entity

Annotations

The delivery process is annotated with

@CoreModel.PlannedEvents



List of planned events for the delivery process that consists of

● PickingCompletedEvent (match location, technical tolerance window 2 hours, business tolerance value 1 hour)● GoodsIssuedEvent (does not match location, technical tolerance window 1 day, business tolerance value 1

hour)● ProofOfDeliveryEvent (does not match location, technical tolerance window 1 minute, business tolerance value

1 hour)

@CoreModel. AdmissibleUnplannedEvents

List of admissible unplanned events

● DelayedEvent

@CoreModel.StatusProperties

List of status attributes that must not be passed via any message

● shippingStatus● deliveryStatus

5.2.4.5 Events

The following events are defined for the delivery application as extension to the generic event as defined in the core model. None of the events have event specific attributes, only annotations.

PickingCompletedEvent

@SAP_EM.eventCode

Code: PICK_COMPL

Type: PLANNED

@CoreModel.UpdateStatus

Field: DeliveryProcess.shippingStatus

New value: 02

GoodsIssuedEvent

@SAP_EM.eventCode

Code: GI

Type: PLANNED




New value: 03

ProofOfDeliveryEvent

@SAP_EM.eventCode

Code: POD

Type: PLANNED



New value: 04

DelayedEvent

@SAP_EM.eventCode

Code: DELAY

Type: UPLANNED


Field: DeliveryProcess.deliveryStatus

New value: 02

5.2.4.6 Entities for Inbound Processing

Within the delivery metadata model we have defined entities for inbound processing.

Delivery Process Inbound

Entity name: DeliveryProcessInbound

Namespace: com.sap.gtt.app.deliverysample

Context: Delivery

Type: projection on Delivery.DeliveryProcess



Description: The entity is used for data mapping during processing of generic messages sent by SAP Event Management

Annotations

Table 29:

Attribute Value Description

@CoreModel.UsageType inboundMessage Entity is used for inbound processing of generic message interface

@SAP_EM.applicationObjectType OBP10_DELIV The entity is used for this application object type

@SAP_EM.primaryTrackingIdType DEL_NO The type of the primary tracking ID (value is passed in field applicationObjectID within the message)

Attributes

Table 30:

Attribute @SAP_EM.fieldname Remarks

deliveryId DEL_NO

salesOrderId SO_NO

shipToParty SHIP_TO_PARTY objectIdentifierType: 'customer'

soldToParty SOLD_TO_PARTY objectIdentifierType: 'customer'

salesOrganization SALES_ORGANIZATION

deliveryDate DELIVERY_DATE

loadingDate LOADING_DATE

transPlanDate TRANS_PLAN_DATE

shippingPoint SHIPPING_POINT

deliveryNetWeight DELIVERY_NET_WEIGHT

deliveryWeightUnit DELIVERY_WEIGHT_UNIT

deliveryVolume DELIVERY_VOLUME

deliveryVolumeUnit DELIVERY_VOLUME_UNIT



shippingType SHIPPING_TYPE

numberOfPackages NO_OF_PACKAGES

purchaseOrderId PO_NO

deliveryWeight DELIVERY_WEIGHT

items itemizedEntity: 'DeliveryProcessItemInbound'

Delivery Process Item Inbound

Entity name: DeliveryProcessItemInbound

Namespace: com.sap.gtt.app.deliverysample

Context: Delivery

Type: projection on Delivery.DeliveryProcessItem

Description: The entity is used for data mapping during processing of generic messages sent by SAP Event Management

Annotations

Table 31:

Attribute Value Description

@CoreModel.UsageType inboundMessage Entity is used for inbound processing of generic message interface

@SAP_EM.applicationObjectType OBP10_DELIV The entity is used for this application object type

@SAP_EM.itemized true The entity maps against indexed parameters from the generic SAP EM inbound message

Attributes



Table 32:


deliveryItem DELIVERY_ITEM

plant PLANT

storageLocation STORAGE_LOC

material MATERIAL

deliveryQty DELIVERY_QTY

qtyUnit QUANTITY_UNIT

pickingQty PICKING_QTY

distributionChannel DISTRIBUTION_CHANNEL

5.2.4.7 Delivery Application Service

The delivery application service extends the core service and exposes in addition the following entities:

Table 33:

Entity Description

DeliveryProcess UI specific projection of the delivery process defined in delivery metadata model

DeliveryItem UI specific projection of delivery item defined in delivery metadata model

DeliveryStatus

Shipping Status

ShippingType

Projection of the corresponding entities in delivery metadata model. Main purpose is the provisioning of value helps.

EventDescription Newly defined entity to provide value help for events with code and description

Extension from Core Service

The application service is extended from the core service. For example, DeliveryService.cds is defined as follows:

namespace com.sap.gtt.app.deliverysample; using com.sap.gtt.app.deliverysample.DeliveryModel from "DeliveryModel";using com.sap.gtt.core.CoreServices.TrackedProcessService from "CoreServices";


using com.sap.gtt.core.CoreModel from "CoreModel";service DeliveryService @extends: TrackedProcessService { @CoreModel.UsageType: #userInterface @CoreModel.MainEntity: true entity DeliveryProcess as projection on DeliveryModel.DeliveryProcess { *, shippingPoint.locationId as shippingPoint @title:'Shipping Point', items : redirected to DeliveryItem, trackingIds : redirected to TrackedProcessService.QualifiedTrackingId, sender : redirected to TrackedProcessService.BusinessPartner, processEvents : redirected to TrackedProcessService.ProcessEventDirectory, shipToParty : redirected to TrackedProcessService.BusinessPartner, soldToParty : redirected to TrackedProcessService.BusinessPartner } excluding { tenant, name, trackedProcessType, trackingIds, lastProcessedEvent, CreatedByUser, CreationDateTime, LastChangedByUser, LastChangeDateTime };}

The following are some important restrictions to be considered when you want to extend your application service from the core service.

● The "using ... from ..." statements must be written in the order from top to bottom of the models. You must import high level models before low level models. The models ordered from top down are:1. DeliveryUI2. DeliveryService3. DeliveryModel4. CoreServices5. CoreModel6. CoreType

● You must use the syntax "@extends:" to extend your application service from the core service. This is a special syntax sugar feature which is only supported for application service models in SAP Global Track and Trace.

● You must use the annotation "@CoreModel.MainEntity: true" on the entity which needs to be displayed in the application UI. For example, "DeliveryProcess" entity in the Delivery Application Service.

5.2.4.8 Delivery Application UI Annotations

The UI annotation file contains the layout definition for delivery processes within SAP Fiori Elements.

The following shows a full example CDS code for Delivery UI annotations. For annotation definition details, see the previous "UI Annotations" section.

Example

An example annotation for a delivery looks like the following:

annotate DeliveryService.DeliveryProcess with @( Common: { Label: 'Delivery', SemanticKey: [ deliveryId ], FilterExpressionRestrictions: [{ Property: deliveryDate,



AllowedExpressions: #SingleInterval, },{ Property: loadingDate, AllowedExpressions: #SingleInterval, },{ Property: transPlanDate, AllowedExpressions: #SingleInterval, }], }, UI: { Identification: [ deliveryId, ], HeaderInfo: { TypeName:'Delivery', TypeNamePlural:'Deliveries', Title: { Label: 'Outbound Delivery', Value: deliveryId }, Description: { Label: 'Track Outbound Delivery', Value: description } }, SelectionFields: [ deliveryId, sender, salesOrganization, deliveryDate, deliveryStatus, shippingStatus ], PresentationVariant: { SortOrder: [ {$Record: [ {$PropertyValue: {Property: 'Property', PropertyPath: 'deliveryId'}}, {$PropertyValue: {Property: 'Descending', Bool: true}} ]} ] }, }, Capabilities: { Insertable:false, Updatable:false, Deletable:false, FilterRestrictions: { NonFilterableProperties: [ description, sender, shipToParty, soldToParty, shippingPoint, to_shippingType, to_deliveryStatus, to_shippingStatus, deliveryWeightUnit, deliveryVolumeUnit, ] }, SortRestrictions: { NonSortableProperties: [ ] }, SearchRestrictions: { Searchable: false } }, //readonly, // => this will set Common.Immutable to all its properties


) { id @title:'ID' @Common.FieldControl:#Hidden; description @title: 'Description'; sender @Common.ValueList.SearchSupported:false; shipToParty @important @Common.SemanticObject:'BusinessPartner' @Common.ValueList.SearchSupported:false; soldToParty @important @Common.SemanticObject:'BusinessPartner' @Common.ValueList.SearchSupported:false;};// Line Items for Listsannotate DeliveryService.DeliveryProcess with @UI.LineItem: [ deliveryId, sender, salesOrderId, purchaseOrderId, shipToParty, salesOrganization, deliveryDate, loadingDate, {Value:deliveryStatus, Criticality:to_deliveryStatus.Criticality, CriticalityRepresentation:#WithoutIcon}, shippingStatus,];// Facets for Object Pageannotate DeliveryService.DeliveryProcess with @( UI.HeaderFacets: [ { Type:'UI.ReferenceFacet', Target: '@UI.FieldGroup#SenderInfo' }, { Type:'UI.ReferenceFacet', Target: '@UI.FieldGroup#TrackingInfo' }, { Type:'UI.ReferenceFacet', Target: '@UI.FieldGroup#shippingStatus' }, { Type:'UI.ReferenceFacet', Target: '@UI.DataPoint#deliveryStatus' }, ], UI.FieldGroup#SenderInfo: { Label: 'Sender', Data: [ sender, logicalSenderSystem, ] }, UI.FieldGroup#TrackingInfo: { Label: 'Tracking ID', Data: [ trackingId, trackingIdType, ] }, UI.FieldGroup#shippingStatus: { Data: [ shippingStatus, ] }, UI.DataPoint#deliveryStatus: { Value:deliveryStatus, Title:'Delivery Status', Criticality:to_deliveryStatus.Criticality }, UI.FieldGroup#SalesAndPurchase: { Label: 'Sales and Purchase', Data: [ salesOrderId, purchaseOrderId, salesOrganization, {Type:'UI.DataFieldForAnnotation', Label:'Ship To Party', Target:'shipToParty/@Communication.Contact'}, {Type:'UI.DataFieldForAnnotation', Label:'Sold To Party', Target:'soldToParty/@Communication.Contact'}, ] }, UI.FieldGroup#ShippingInformation: {



Label: 'Shipping Information', Data: [ shippingType, shippingPoint, transPlanDate, loadingDate, deliveryDate, ] }, UI.FieldGroup#PackageDetails: { Label: 'Package Details', Data: [ numberOfPackages, deliveryVolume, deliveryWeight, deliveryNetWeight, ] }, UI.Facets: [ { Type: 'UI.CollectionFacet', ID: 'BusinessProcess', Label: 'Business Process', Facets: [ { Type: 'UI.CollectionFacet', ID: 'DetailInfo', Label: 'Detailed Information', Facets: [ { Type:'UI.ReferenceFacet', Target: '@UI.FieldGroup#SalesAndPurchase' }, { Type:'UI.ReferenceFacet', Target: '@UI.FieldGroup#ShippingInformation' }, { Type:'UI.ReferenceFacet', Target: '@UI.FieldGroup#PackageDetails' }, ] }, { Type:'UI.CollectionFacet', ID:'DeliveryItems', Label:'Delivery Items', Facets: [ { Type:'UI.ReferenceFacet', Target: 'items/@UI.LineItem' }, ] }, { Type:'UI.CollectionFacet', ID:'Events', Label:'Event Messages', Facets: [ { Type:'UI.ReferenceFacet', Target: 'processEvents/@UI.LineItem#GenericEvents' }, ] } ] } ]);annotate DeliveryService.DeliveryProcess with { deliveryStatus @ValueList:{ type:#fixed, entity:'DeliveryStatus' }; shippingStatus @ValueList:{ type:#fixed, entity:'ShippingStatus' }; shippingType @ValueList:{ type:#fixed, entity:'ShippingType' };};//////////////////////////////////////////////////////////////////////////////// Annotations for DeliveryItem//annotate DeliveryService.DeliveryItem with @( Capabilities: { Insertable:false, Updatable:false, Deletable:false,


FilterRestrictions: { NonFilterableProperties: [ deliveryItem, distributionChannel, plant, storageLocation, material, deliveryQty, pickingQty, ] }, SortRestrictions: { NonSortableProperties: [ deliveryItem, distributionChannel, plant, storageLocation, material, deliveryQty, pickingQty, ] }, },) { // Element-level Annotations delivery @Common.FieldControl:#Hidden; qtyUnit @Common.FieldControl:#Hidden;};// Line Item for DeliveryItemsannotate DeliveryService.DeliveryItem with @UI.LineItem: [ deliveryItem, material, deliveryQty, pickingQty];

Related Information

UI Annotations [page 80]

5.2.5 Shipment Application Details

The shipment application comes with additional metadata model definition that extends the generic tracked process definition with shipment specific fields. The definitions are similar with those in the delivery application, which are described in the previous section.

Standard Mode Shipment Application

A standard mode shipment application consists of three files.



Table 34:


ShipmentModel.cds com.sap.gtt.app.shipmentsample

ShipmentModel Defines the metadata model (tracked processes and events) for the shipment application.

ShipmentService.cds com.sap.gtt.app.shipmentsample

ShipmentService Exposes the necessary entities as a service.

ShipmentUI.cds com.sap.gtt.app.shipmentsample

Not applicable Provides the UI annotations for Fiori Elements of the shipment application.

Simple Mode Shipment Application

A simple mode shipment application only consists of one model CDS file with model information and basic UI layout information.

5.2.5.1 Map-related Functions in a Shipment Process

In the GTT app, you can track a shipment process which includes a map view for monitoring event locations, current process locations, and shipping routes. To enable these map-related functions, you must add relevant scripts to your metadata model. The example below shows how to modify a shipment template model to enable map-related functions.

Prerequisites

Before adding map-related functions, you must first display a map-view tab on the process' details page as follows.

Standard Mode

In the ShipmentUI.cds file, add the below scripts under UI.Facets:

{ $Type: 'UI.ReferenceFacet', ID: 'ProcessGeoMap', Label: 'Map',}


Simple ModeIn the ShipmentModel.cds file, annotate the ShipmentProcess entity with:

@CoreModel.MapEnabled: true

Step 1 - Display Event Locations on the Map

Standard Mode1. In the ShipmentModel.cds file, add the processLocations property to ShipmentProcess as shown below:

processLocations : Association to many CoreModel.ProcessLocation on processLocations.process = $self;

2. In the ShipmentUI.cds file, annotate processLocations of ShipmentProcess as shown below:

processLocations @UIExt.GeoMap.FacetID:'ProcessGeoMap';

Simple Mode● In the ShipmentModel.cds file, add the processLocations property to ShipmentProcess as shown below:

processLocations : Association to many CoreModel.ProcessLocation on processLocations.process = $self;

Step 2 - Display Shipping Routes on the Map

For both the standard mode and the simple mode, in the ShipmentModel.cds file, add the processRoutes property to ShipmentProcess, as shown below:

processRoutes: Association to many CoreModel.ProcessRoute on processRoutes.process = $self;

Step 3 - Display Current Process Locations on the Map

For both the standard mode and the simple mode, in the ShipmentModel.cds file, add the currentProcessLocations, longtitude, latitude and currentLocationTimestamp properties to ShipmentProcess, as shown below:

currentProcessLocations: Association to many CoreModel.CurrentProcessLocation on currentProcessLocations.process = $self; @CoreModel.Map.CurrentProcessLocation.Longitude: truelongitude: Decimal(9,6) @title:'Longitude';@CoreModel.Map.CurrentProcessLocation.Latitude: truelatitud : Decimal(8,6) @title:'Latitude';@CoreModel.Map.CurrentProcessLocation.UpdateTimestamp: truecurrentLocationTimestamp: Timestamp;



Important Disclaimers and Legal Information

Coding SamplesAny software coding and/or code lines / strings ("Code") included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, unless damages were caused by SAP intentionally or by SAP's gross negligence.

AccessibilityThe information contained in the SAP documentation represents SAP's current view of accessibility criteria as of the date of publication; it is in no way intended to be a binding guideline on how to ensure accessibility of software products. SAP in particular disclaims any liability in relation to this document. This disclaimer, however, does not apply in cases of willful misconduct or gross negligence of SAP. Furthermore, this document does not result in any direct or indirect contractual obligations of SAP.

Gender-Neutral LanguageAs far as possible, SAP documentation is gender neutral. Depending on the context, the reader is addressed directly with "you", or a gender-neutral noun (such as "sales person" or "working days") is used. If when referring to members of both sexes, however, the third-person singular cannot be avoided or a gender-neutral noun does not exist, SAP reserves the right to use the masculine form of the noun and pronoun. This is to ensure that the documentation remains comprehensible.

Internet HyperlinksThe SAP documentation may contain hyperlinks to the Internet. These hyperlinks are intended to serve as a hint about where to find related information. SAP does not warrant the availability and correctness of this related information or the ability of this information to serve a particular purpose. SAP shall not be liable for any damages caused by the use of related information unless damages have been caused by SAP's gross negligence or willful misconduct. All links are categorized for transparency (see: http://help.sap.com/disclaimer).


Important Disclaimers and Legal Information

http://help.sap.com/disclaimer/

Metadata Modeling AppImportant Disclaimers and Legal Information P U B L I C 115

go.sap.com/registration/contact.html

© 2017 SAP SE or an SAP affiliate company. All rights reserved.No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. The information contained herein may be changed without prior notice.Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary.These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.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.Please see http://www.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices.

https://go.sap.com/registration/contact.html

https://go.sap.com/registration/contact.html

http://www.sap.com/corporate-en/legal/copyright/index.epx

http://www.sap.com/corporate-en/legal/copyright/index.epx

Global Track and Trace Plugin for SAP Web IDE · PDF fileThe MM app is an SAP Web IDE plugin,...

Documents

Transcript of Global Track and Trace Plugin for SAP Web IDE · PDF fileThe MM app is an SAP Web IDE plugin,...