Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
minLevel1
maxLevel24
outlinefalse
styledefault
typelist
printablefalse

What is an Automation App?

An automation app in PIPEFORCE is like an app for mobile phones. Such an app groups together resources like scripts, templates, configurations and others to solve a certain business task. Any automation pipeline, form or , workflow etc. is part of exactly one app. Such an app is the logical unit of an automation solution having a unique name.

An automation app can be shared with others on the marketplace and installed, updated or uninstalled using commands.

For each automation app, certain access rules can be specified. Furthermore, it is also possible to use staging and versioning for automation apps. They can be developed online using the workbench or offline using source files and the CLI. You can think of automation apps also like “plug-ins” for PIPEFORCE which can be installed and updated at runtime.

Also see this tutorial to learn how to create an automation app in PIPEFORCE.

Info

For simplicity reasons, automation apps will sometimes also be called just apps in PIPEFORCE.

App home folder

Typically, all properties (resources) of an app reside in the property store and having a property path with a prefix like this:

...

This path is called the app home folder.

Qualified app naming

In order to avoid a naming clash with other apps from other users which could probably have the same naming as your app, as best practise, you should give the app always a name which follows the reversed domain name package conventions from the Java package specification, which works like this:

...

Info

The internet domain names of your app prefixes must be valid ones if you want your apps to become trusted in the marketplace.

App folders and resources

Inside of an app path, there is a certain folder structure at top app home folder level which defines the main resource types of an app. Depending on in which folders properties are stored inside an app, auto-backend tasks could be fired. The typical folder structure looks like this (the folders could vary, depending on your setup):

Naming convention

Any resource inside an app should follow this naming convention:

...

Code Block
global/app/tld.domain.myapp/pipeline/001-send-invite-email
global/app/tld.domain.myapp/pipeline/A1-upload-invoice
global/app/tld.domain.myapp/pipeline/add-to-sap
global/app/tld.domain.myapp/pipeline/inform-hr

/

...

config

This optional folder contains all form configurations for any form of the app, whereas the name of the property is the name of the form. For example:

Code Block
global/app/tld.domain.myapp/form/create-user
global/app/tld.domain.myapp/form/delete-user

/function

This optional folder contains all Python FaaS functions which will be automatically deployed when such a property of this app is stored in the property store in this folder.

For more information see: Python Functions

Info

Any time the hub service restarts (for example because of rescaling), all function scripts inside this folder will be automatically scanned and re-deployed to the FaaS backend if required.

/install

Status
colourBlue
titleSInce Version 9.0

This optional folder can also contain pipeline YAML scripts. These pipelines will be executed only in case the app will be installed using the app.install command.

This is handy in case you would like to do some preparation on the install phase of an app.

The pipelines will be executed in their natural naming order. So if you would like to make sure a pipeline gets executed the very first, make sure it is at the very top of the naming order by using prefixes like 001-, 002- and so on.

Info

The pipelines in this folder wont be auto-executed on save of properties in the portal or on publish using the CLI or on hub restart. Only the initial app.install will execute them.

/list

This optional folder contains all list configuration properties for any list of the app, whereas the name of the property is the name of the list. For exampleapp specific configuration properties.

/app

The default configuration property for an app is the app property. This is automatically created if you create an app via CLI or the online property wizard. It is a JSON document of this basic format:

Code Block
languagejson
{
  "title": "My App",
  "description": "The description of the app",
  "icon": "some_icon_id",
  "color": "teal-8",
  "hidden": false,
  "tags": [
    "admin"
  ],
  "permissions": {
    "read": [
      "CAN_APP_io.pipeforce.myapp",
      "ROLE_ADMIN",
      "ROLE_DEVELOPER"
    ],
    "write": [
      "CAN_APP_io.pipeforce.myapp",
      "ROLE_ADMIN",
      "ROLE_DEVELOPER"
    ],
    "view": [
      "CAN_APP_io.pipeforce.myapp",
      "ROLE_ADMIN",
      "ROLE_DEVELOPER"
    ]
  }
}

"title"

The short title of the app. Can optionally be a $uri:i18n key for translations.

"description"

The description of the app. Can optionally be a $uri:i18n key for translations. Can be empty.

"icon"

The id of the Google Material icon to be used for this app. See here for listing of all available icons: https://fonts.google.com/icons . Note: Make sure to use the id of the icon not its name. If no icon is set, the system default icon will be used.

"color"

The color to be used for the app icon. If not set, the default color will be used. Also see here: Colors for more details about supported color codes.

"hidden"

An optional flag. If true, the app wont be shown in the apps listing in the portal. The default value is false.

"tags"

A list of optional search keywords. This improves finding this app via UI search.

"permissions"

Defines the required permissions for this app.

  • read = A list of ROLES, the logged-in user must be member of (at least in one of it) to be able to read values in this app (for example list properties / data stored in this app).

  • write = A list of ROLES, the logged-in user must be member of (at least in one of it) to be able to write values in this app (for example properties / data to the property store, submit forms).

  • view = A list of ROLES, the logged-in user must be member of (at least in one of it) to be able to see the app tiles, forms and lists in the web UI.

/data

In case there are data objects (JSON documents), typically based on a schema, they should be stored inside this path structure:

Code Block
global/app/tld.domain.myapp/data/<NAME>/<UUID>

Whereas <NAME> is the name of the data object.

<UUID> is the unique id of a single data object.

For example:

Code Block
global/app/tld.domain.myapp/data/person/fa471958-fdb7-4bf6-a0a3-c5e8c782893e

Each instance property will contain as value the data of the object instance which typically matches the schema, for example:

Code Block
languagejson
{
  "firstName": "Homer",
  "lastName": "Simpson",
  "age": 48,
  "gender": "male"
}
Info

Note: In case of an update of an app, the data folder wont be deleted by default. See the options of the app.update and app.install commands for more details.

/form

This optional folder contains all form configurations for any form of the app, whereas the name of the property is the name of the form. For example:

Code Block
global/app/tld.domain.myapp/form/create-user
global/app/tld.domain.myapp/form/delete-user

See here for more details: Forms Framework

/function

This optional folder contains all Python FaaS functions which will be automatically deployed when such a property of this app is stored in the property store in this folder.

For more information see: Python Functions

Info

Any time the hub service restarts (for example because of rescaling), all function scripts inside this folder will be automatically scanned and re-deployed to the FaaS backend if required.

/i18n

This optional folder contains all internationalization (i18n) files like message files and other resources.
Also see: Internationalization (i18n).

/install

Status
colourBlue
titleSInce Version 9.0

This optional folder can also contain pipeline YAML scripts. These pipelines will be executed only in case the app will be installed using the app.install or app.update command.

This is handy in case you would like to do some preparation on the install or update phase of an app like migrations for example.

The pipelines will be executed in their natural naming order. So if you would like to make sure a pipeline gets executed the very first, make sure it is at the very top of the naming order by using prefixes like 001-, 002- and so on.

Info

The pipelines in this folder wont be auto-executed on save of properties in the portal or on publish using the CLI or on hub restart. Only the initial app.install will execute them.

/list

This optional folder contains all list configuration properties for any list of the app, whereas the name of the property is the name of the list. For example:

Code Block
global/app/tld.domain.myapp/list/all-users
global/app/tld.domain.myapp/list/all-employees

See here for more details: List Framework

/object (deprecated)

Note

DEPRECATED since

Status
colourBlue
titleVERSION 9.0
. Use /data folder instead.

This optional folder contains any application model (schema) and its instances (if there are any).

/schema (deprecated)

Note

Folder /object/schema is DEPRECATED since

Status
colourBlue
titleVERSION 9.0
. Use /schema folder in app root instead.

The schema of an object is stored in a property having this path:

Code Block
global/app/tld.domain.myapp/object/<NAME>/<VERSION>/schema

Whereas <NAME> is the name of the object.

<VERSION> is the version of the object schema.

For example:

Code Block
object/person/v1/schema

The schema property typically contains as value a JSON schema, which describes this object. For the person object, the schema could, for example, look like this:

Code Block
languagejson
{
  "type": "object",

  "properties": {
    "firstName": {
      "type": "string"
    },
    "lastName": {
      "type": "string"
    },
    "age": {
      "type": "number"
    },
    "gender": {
      "type": "string",
      "enum": ["male", "female", "neutral"]
    }
  }
}

See the JSON schema section for more details: JSON Schema

/instance​ (deprecated)

Note

DEPRECATED since

Status
colourBlue
titleVERSION 9.0
. Use /data folder instead.

In case there are object instances (JSON documents) based on a schema, they should be typically stored inside this path structure:

Code Block
global/app/tld.domain.myapp/list/all-users
/object/<NAME>/<VERSION>/instance/<UUID>

Whereas <NAME> is the name of the object.

<VERSION> is the version of the object schema.

<UUID> is the unique id of a single object.

For example:

Code Block
global/app/tld.domain.myapp/list/all-employees

/object

This optional folder contains any application model (schema) and its instances (if there are any).

/schema

The schema of an object is stored in a property having this path:

Code Block
global/app/tld.domain.myapp/object/<NAME>/<VERSION>/schema

Whereas <NAME> is the name of the object.

<VERSION> is the version of the object schema.

For example:

Code Block
object/person/v1/schema

The schema property typically contains as value a JSON schema, which describes this object. For the person object, the schema could, for example, look like this:

Code Block
languagejson
{
  "type": "object",

  "properties": {
    "firstName": {
      "type": "string"
    },
    "lastName": {
      "type": "string"
    },
    "age": {
      "type": "number"
    },
    "gender": {
      "type": "string",
      "enum": ["male", "female", "neutral"]
    }
  }
}

See the JSON schema section for more details: JSON Schema

/instance​

...

/object/person/v1/instance/fa471958-fdb7-4bf6-a0a3-c5e8c782893e

Each instance property will contain as value the data of the object instance which matches the object schema, for example:

Code Block
languagejson
{
  "firstName": "Homer",
  "lastName": "Simpson",
  "age": 48,
  "gender": "male"
}

/pipeline

This optional folder contains all persisted pipeline YAML scripts for the given app. A pipeline can be seen as the business logic or data integration part of an application.

Each property name corresponds with the name of the pipeline and contains as value the pipeline YAML script.

Examples:

Code Block
global/app/tld.domain.myapp/pipeline/001-send-invite-email
global/app/tld.domain.myapp/pipeline/add-to-sap
global/app/tld.domain.myapp/pipeline/inform-hr

Such a pipeline YAML script could look like this:

Code Block
languageyaml
pipeline:
  - mail.send:
      to: hr@company.de
      subject: "A new employee was addded!"

Also see Automation Pipeline for more details how to create persisted pipelines.

Info

Any time the hub service restarts (for example because of rescaling), all pipeline scripts inside this folder (recursively) will be automatically scanned and any trigger command inside each pipeline will be re-registered (for example jobs, message listeners, …).

/report

This optional folder can contain all report configurations.

See here for more details: Reporting Framework

/resource

This optional folder can contain any resource required inside the app. For example images, CSS files or similar.

/schema

The schema of an data object is stored in a property having this path:

Code Block
global/app/tld.domain.myapp/schema/<NAME>

Whereas <NAME> is the name of the data object this schema stands for.

For example:

Code Block
global/app/tld.domain.myapp/object/<NAME>/<VERSION>/instance/<UUID>

Whereas <NAME> is the name of the object.

<VERSION> is the version of the object schema.

<UUID> is the unique id of a single object.

For example:

Code Block
global/app/tld.domain.myapp/object/person/v1/instance/fa471958-fdb7-4bf6-a0a3-c5e8c782893e

Each instance property will contain as value the data of the object instance which matches the object schema, for example:

Code Block
languagejson
{
  "firstName": "Homer",
  "lastName": "Simpson",
  "age": 48,
  "gender": "male"
}

/pipeline

This optional folder contains all persisted pipeline YAML scripts for the given app. A pipeline can be seen as the business logic or data integration part of an application.

Each property name corresponds with the name of the pipeline and contains as value the pipeline YAML script.

Examples:

Code Block
global/app/tld.domain.myapp/pipeline/001-send-invite-email
global/app/tld.domain.myapp/pipeline/add-to-sap
global/app/tld.domain.myapp/pipeline/inform-hr

Such a pipeline YAML script could look like this:

Code Block
languageyaml
pipeline:
  - mail.send:
      to: hr@company.de
      subject: "A new employee was addded!"

Also see Command and Pipeline for more details how to create persisted pipelines.

Info

Any time the hub service restarts (for example because of rescaling), all pipeline scripts inside this folder (recursively) will be automatically scanned and any trigger command inside each pipeline will be re-registered (for example jobs, message listeners, …).

...

schema/person

The schema property typically contains as value a JSON schema, which describes this object. For the person object, the schema could, for example, look like this:

Code Block
languagejson
{
  "type": "object",

  "properties": {
    "firstName": {
      "type": "string"
    },
    "lastName": {
      "type": "string"
    },
    "age": {
      "type": "number"
    },
    "gender": {
      "type": "string",
      "enum": ["male", "female", "neutral"]
    }
  }
}

See the JSON schema section for more details: JSON Schema

/setup (deprecated)

Note

DEPRECATED since

Status
colourBlue
titleVERSION 9.0
. Use /install folder instead.

This optional folder can also contain pipeline YAML scripts. These pipelines will be executed only in case the app will be installed using the app.install command.

This is handy in case you would like to do some preparation on setup phase of an app.

The pipelines will be executed in their natural naming order. So if you would like to make sure a pipeline gets executed the very first, make sure it is at the very top of the naming order by using prefixes like 001-, 002- and so on.

Info

The pipelines in this folder wont be auto-executed on save of properties in the portal or on publish using the CLI or on hub restart. Only the inital app.install will execute them.

/script (deprecated)

Note

DEPRECATED since

Note

DEPRECATED since

Status
colourBlue
titleVERSION 9.0
. Use /function folder instead.
Status
colourBlue
titleVERSION 9.0
. Use /install folder instead.

This optional folder can also contain pipeline YAML scripts. These pipelines will be executed only in case the app will be installed using the app.install command.

This is handy in case you would like to do some preparation on setup phase of an app.

The pipelines will be executed in their natural naming order. So if you would like to make sure a pipeline gets executed the very first, make sure it is at the very top of the naming order by using prefixes like 001-, 002- and so on.

Info

The pipelines in this folder wont be auto-executed on save of properties in the portal or on publish using the CLI or on hub restart. Only the inital app.install will execute them.

/script

titleVERSION 9.0
. Use /function folder instead.

/system

This folder contains all system related backend data of this specific app. For example tmp data, workflow or form data. It is not meant for manual handling and you should not be required to touch or change content in it. It is fully managed by the platform.

Info

Note: By default this folder wont be deleted on app.install or app.update.

/template

This optional folder should contains all templates like FreeMarker templates an others.

See here for more details: Template Transformation

/test

This optional folder typically contains pipelines for tests only. Whenever necessary, PIPEFORCE automatically executes the test pipelines inside this folder to make sure the app is working as expected. Therefore you have to make sure that these tests can be executed at any time and are fully reentrant (once a test has been finished it can be executed again as often as necessary).

...

The property contains the test pipeline as value. Such a test pipeline could look like this:

Code Block
languageyaml
pipeline:
  - testassert:
      assertTrue(false) true: ${someTestExpression}

See here for more details: Testing Automation Apps

/uninstall

Status
colourBlue
titleSInce Version 9.0

...

Info

The pipelines in this folder wont be auto-executed on save of properties in the portal or on publish using the CLI or on hub restart. So triggers in these pipelines wont work. Only a call of app.uninstall will execute them.

/update

Status
colourBlue
titleSInce Version 910.0.1

This optional folder can also contain folder is optional and contains all migration pipeline YAML scripts in order to migrate from one app version to another. These pipelines will be executed only in case the app will be updated installed using the app.update command.This is handy in case you would like to do some update and migration tasks on update.

The pipelines will be executed in their natural naming order. So if you would like to make sure a pipeline gets executed the very first, make sure it is at the very top of the naming order by using prefixes like 001-, 002- and so on.

Info

The pipelines in this folder wont be auto-executed on save of properties in the portal or on publish using the CLI or on hub restart. So triggers in these pipelines wont work. Only a call of app.update will auto-execute them.

/workflow

This optional folder contains any BPMN workflow files defining a business process.

...

Code Block
global/app/tld.domain.myapp/workflow/approve-new-employee

See here for more details: BPMN Workflows

Developing an automation app

In its simple case you can manage all properties of an app in the property store with the property.* commands and the CLI using pi publish or using the online workbench.

...