Introduction

An InsightProvider (ipro) is a plugin-like extension of an pdms application. An InsightProvider normally consists of ui, backend and db layer. This document sap-pdms-ipro-api focuses on the ui contract / interfacing between an pdms application and and ipro. As per this spec the ipro ui has to have a javascript based entrypoint which exposes a javascript class that implements the InsightProvider interface. All ipros share a common set of properties:

• Ipros are created by using a static factory method create.
• Ipros are independent of each other in the sense that they never rely on any other ipro being present for functioning properly.
• Ipros can be implemented using different UI technologies (e.g. UI5, native Javascript, etc.)
• Ipros are dynamically loaded by an application as a module. PDMS applications use system.js to manage modules. That means that an ipro implementation can use any module system supported by system.js.
• The primary input of ipros are sets of entities, which are also referred to as contexts. All operations that an ipro implements are directly or indirectly referring to such a context. Entities of type "Primary Object" have a special connotation. Primary objects (which are indeed assets in the current PDM scenarios) are of special importance to the application since all analysis and information gathering within a PDMS application is centered around them. They can be thought of as the glue that synchronizes the behavior of the involved ipros. Ipros can choose to be notified whenever the context changes as well as inform interested parties whenever its context has changed. By listening to context changes induced by ipros applications can communicate these context changes to other ipros. This way an application can establish communication between ipros by mediating context changes.

Entities and Entity Types

PDMS applications introduce the notion of an entity type. An entity type usually represents a business or technical object like machines, warranties, alerts, time series, etc. Actors of a PDMS application (i.e. application and ipros) do not make any assumptions about the structure or behavior of entities nor does the usage of an entity type needs to be declared upfront. The only aspect that needs to be enforced is that each entity type has one unique name.

Entity types are used to manage parameter flows between ipros. If one ipro outputs entities of a given entity type that another ipro declares as an input an application can match these ipros and realize the required data flow. Entities can be either represented as identifiers (i.e. strings) or as plain objects. In the latter case a consumer cannot make any strict assumptions about the structure of these entities. Therefore a consumer should only use introspection to explore what properties are present in a given entity.

Implementation

Technically, an ipro is a JavaScript file named ipro.js. It contains a module that can be adhere to any of the module frameworks supported by systemjs. However, it is important to note that using commonjs or ES6 modules requires transpilation while requirejs modules are supported without transpilation.