...
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/form/create-user 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/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 | ||||
---|---|---|---|---|
|
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 |
/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-usersperson/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 | ||
---|---|---|
| ||
{
"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 |
/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/listform/alldelete-employeesuser |
See here for more details: List Forms Framework
/
...
function
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 | ||
---|---|---|
| ||
{
"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
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/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 | ||
---|---|---|
| ||
{
"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 | ||
---|---|---|
| ||
pipeline:
- mail.send:
to: hr@company.de
subject: "A new employee was addded!" |
Also see Data 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.
/setup
Note | ||||||
---|---|---|---|---|---|---|
DEPRECATED since
/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 |
/script
Note | ||||||
---|---|---|---|---|---|---|
DEPRECATED since
/function folder instead. |
/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).
For example:
Code Block |
---|
global/app/tld.domain.myapp/test/create-user |
The property contains the test pipeline as value. Such a test pipeline could look like this:
Code Block | ||
---|---|---|
| ||
pipeline:
- assert:
true: ${someTestExpression} |
See here for more details: Testing
...
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 | ||||
---|---|---|---|---|
|
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 |
/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
/data folder instead. |
This optional folder contains any application model (schema) and its instances (if there are any).
/schema
(deprecated)
Note | ||||||
---|---|---|---|---|---|---|
Folder
/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 | ||
---|---|---|
| ||
{
"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
/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/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 | ||
---|---|---|
| ||
{
"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 | ||
---|---|---|
| ||
pipeline:
- mail.send:
to: hr@company.de
subject: "A new employee was addded!" |
Also see Data 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/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 | ||
---|---|---|
| ||
{
"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
/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 |
/script
(deprecated)
Note | ||||||
---|---|---|---|---|---|---|
DEPRECATED since
/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 |
/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).
For example:
Code Block |
---|
global/app/tld.domain.myapp/test/create-user |
The property contains the test pipeline as value. Such a test pipeline could look like this:
Code Block | ||
---|---|---|
| ||
pipeline:
- assert:
true: ${someTestExpression} |
See here for more details: Testing
/uninstall
Status | ||||
---|---|---|---|---|
|
This optional folder can also contain pipeline YAML scripts. These pipelines will be executed only in case the app will be uninstalled using the app.uninstall
command.
This is handy in case you would like to do some preparation before uninstall.
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 |
/update
Status | ||||
---|---|---|---|---|
|
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 uninstalled installed using the app.uninstallupdate
command.
This is handy in case you would like to do some preparation before uninstall.
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 |
/workflow
This optional folder contains any BPMN workflow files defining a business process.
...