FAQ about PAS

Scheer PAS uses BPMN and UML to create microservices that are directly executed without source code generation. We call them xUML services.

With the PAS Designer, you can model your business processes in BPMN, design your forms, add some execution, and compile all to an xUML service. The validation and compilation is done continuously in the background while you are working on your model.

Compiled xUML services, then, can be deployed to and executed by the xUML Runtime. Using the Scheer PAS Analyzer, you can directly debug and analyze your model, not some generated source code.

The Designer allows to create BPMN models in combination with UML execution, Data Mapping and Forms in a way that serves as process documentation, and in the same time as production service.

xUML services are platform independent. Their logic is modeled as flows that are triggered by modeled endpoints, such as REST, Schedulers and Timers.
The (asynchronous) process logic is modeled as BPMN, completed by (synchronous) UML activities that implement the execution.

All that is compiled into a platform independent xUML service repository that translates the modeled logic into an UML state machine. This state machine handles the actual process. Refer to xUML Service State Machines for more details on the state machine and related options.

Go to chapter Technical Concepts in the Designer Guide for more detailed information about the xUML service interface, form communication, or the xUML Runtime architecture and transaction concept.

If you want to use Scheer PAS in the cloud, all you need is an up-to-date web browser on your computer. Scheer PAS offers a variety of interaction options with its user interface ("Rich Internet Application") and uses HTML5.

Therefore, a powerful, modern browser with JavaScript and Websocket support is required to run Process Apps. The network environment must allow SSL and Websocket requests.

Scheer PAS supports the latest versions of the following browsers:

• Google Chrome

• Mozilla Firefox

• Microsoft Edge

Scheer PAS can also be installed "on-Premises" if desired. The product is then set up on a server provided by the customer. The technical platform, database and integration services are provided.

Refer to Scheer PAS System Requirements for details.

Designing xUML services with Scheer PAS Designer is a four-step process:

1. Model your process in BPMN.

2. Design forms that provide and show necessary data.

3. Process the data by adding execution to your BPMN model, and create a service that is ready to deploy.

4. Test your service.

Refer to Development Approach in the Designer Guide for more details.

Processes are based on data that is going in, is processed, and coming out. This data is specified by data types.
Data types can be structured into packages or interfaces. They are defined by classes and their properties, and have related operations and their parameters.

So if you want to start modeling your processes in Scheer PAS, you need to describe the data that is being used during your process.
To do this, you can

• use the built-in Base Types

• import one or more libraries that contain the necessary data types

• create your own data model (implementation) with the Designer

Refer to Concepts of Data Modeling for more detailed information.

Scheer PAS Designer comes with a set of adapters that allow you to access a variety of backends via different interfaces.

Some adapters are based on standard interfaces and can be used out of the box. These are

• Apache Kafka Producer Adapter

• Filesystem Adapter

• Flat File Adapter

• JSON Adapter

• Logger Adapter

• Memory Adapter

• MongoDB Adapter

• S3 Adapter

• SQL Adapter

Some adapters are designed to connect to custom interfaces that may vary depending on the backend. These are

• REST Adapter

• SAP Adapter

• URL Adapter

Refer to the related adapter pages for more information on how these adapters can be configured.

If you want to enable external users to consume your API, you need to publish it to the API Developer Portal.
Refer to Developer Portal in the API Management Guide.

How the user can access / consume your API depends on the API type. Refer to Subscribing to a Private API and to Consuming a Public API for details.

Instead of creating an API, you can import it from the PAS Administration. Refer to Importing APIs in the API Management Guide for a detailed step-by-step instruction.

Before you can publish your API, you need to finish its configuration. Refer to Configuring an API in the API Management Guide for an overview on all necessary configuration steps.

APIs represent real backend APIs (Application Programming Interfaces). An API is also known as a service, which offers a HTTP, REST or SOAP interface that can be invoked remotely by a client.

Scheer PAS API Management provides a way to turn unmanaged (raw) back-end APIs into managed APIs by attaching policies to them. Any policies configured on an API will be applied at runtime, regardless of the client and API contract.

An API has to be fully configured, including policies and implementation (and in case of public APIs including plans) to be published. If the API has been published to the gateway it can be consumed - in case of private APIs by clients.

Refer to APIs in the API Management Guide for details.

Scheer PAS API Management supports the creation and management of two different types of APIs: public APIs and private APIs.

A private API cannot be consumed by everyone: They require an API Key in order to be called. To consume a private API, a client and a contract must be created. Compared to a public API, private APIs require more complex configuration. But you can control the access to private APIs in a very fine-grained manner, you have insight into various metrics that can be displayed per client and you can map different access levels by assigning restricted usage plans to a private API.

Refer to API Types: Public vs. Private in the API Management Guide for more detailed information.

Scheer PAS API Management supports the creation and management of two different types of APIs: public APIs and private APIs.

A public API can be consumed by everyone (assuming no additional security policy has been set). It is also very easy to consume a public API: You just need to know its public endpoint. Clients do not need to register for a public API: Neither a client nor a contract are necessary. Compared to a private API, a public API requires less configuration.

Refer to API Types: Public vs. Private in the API Management Guide for more detailed information.

A client is the consumer of the API and is only required to use private APIs. Each client can consume multiple APIs within API Management. The relation between client and API is defined via a contract and a plan. As with an API or a plan, you can also add policies to a client.

When a client version is created, the system generates a unique API Key. This key is unique per client and the same for all contracts of this client version. All requests made to the API by a client through the gateway must include this API Key to identify the used client version.

Refer to Clients in the API Management Guide for more detailed information.

A contract is a link between a client and an API through a plan offered by that API. A contract is necessary if a client wants to consume a private API, it cannot be created between a client and a public API. API contracts can only be created between clients and published APIs which are offered through at least one plan.

Refer to Contracts in the API Management Guide for more detailed information.

An organization is a container of other elements: plans, APIs, and clients are defined in the organization. An organization contains and manages all elements used by a company, department, etc. within API Management.

Every user must be associated with at least one organization to be able to manage elements in the application. Scheer PAS API Management implements role-based access control for users. The organization membership of a user defines the actions he is able to perform and the elements he can manage within the organization. Before any other actions can be taken, an organization must exist. All other operations take place within the context of an organization.

Refer to Organizations in the API Management Guide for more details.

A policy is a rule or a set of rules API Management uses to manage access to your APIs. Policies are applied to all API requests and represent a unit of work applied at runtime to the request by API Management.

Policies are applied through a policy chain: when a request to an API is made, API Management creates a chain of policies to be applied to that request. The policy chain is applied to the request in a fixed order: Client policies are applied first, then policies added to plans, and finally policies added to the API itself.

Refer to Policies in the API Management Guide for more details.

The API Developer Portal allows you to grant customer developers access to your APIs. In the Developer Portal, developers can sign up for APIs, access them, and try out APIs that you have enabled for them. The portal is designed to keep the discovery and use of APIs simple for the target group. 

Refer to Developer Portal in the API Management Guide for more details.

The visibility concept of API Management defines which user groups can find the APIs in the Developer Portal. The visibility resides on top of the permission system as another security layer. Visibilities are applicable to public APIs and plans for private APIs. Three different visibilities are available: Organization members (default), API Management users, and API Developer Portal users.

Refer to The Concepts of API Management in the API Management Guide for more details.

For xUML services that have been deployed from the Designer as a container, secured endpoints are created automatically. However, these services are only usable internally and are not exposed to users outside the company. You have access to these endpoints via the service details in the PAS Administration. Refer to Controlling Containerized xUML Services (Docker) or Controlling Containerized xUML Services (Kubernetes) depending on your PAS setup.

If you want to make the APIs available to others, you can publish them via Scheer PAS API Management and restrict their usage with additional policies.
Refer to Exposing Designer Services via API Management in the API Management Guide for a detailed description.

In a Designer service, you can access data from BPMN process instances from the outside, e.g. from another Designer service.

This can be done in two ways:

• by using the xUML Runtime API to query for persistent state objects or

• by using the REST API of the service itself.

Refer to Querying Persistent State Objects via the Runtime API and Querying Persistent State Objects via the Service API for detailed explanation.

You have direct access to the service logs via button Log Analyzer on the service details page.
Refer to Service Deployment Details in the Designer Guide for more details.

The logs are displayed in the PAS Log Analyzer. Refer to Analyzing Platform Logs in the Administration Guide for more information.

You have modeled and tested a process and want to transfer it from your development system to the productive system? Visit Going Live with a Designer Service for a detailed description on how to do that.

If you want to deploy your services to the integration component, you must create an additional user in the Bridge (with the same user name as in the user management). If the deployment to the integration component constantly fails, ask a user management administrator to check if you have a user in the Bridge on your system.

Refer to Managing Users in a Scheer PAS Environment in the Integration Platform User’s Guide for details.

Maybe you have only read permission on the Designer service or on the folder the service resides in. Refer to Folders > Managing the Folder Permissions / Services > Managing the Service Permissions to find out how to check that.

If you have write permission on the folder and the service, ask a user management administrator to check if you have write permission on the namespace.
Refer to Editing a User > Granting Write Permission on Profiles in the Administration Guide for details.

If the content of the Designer looks strange, for example some panels are empty or do not show all content, try a Panel Reset.
Go to the user preferences, select menu Designer Options and click Reset Panels.

You can add one ore more execution models to an execution diagram because the time of execution can be different. For each execution model a corresponding tab is displayed at the bottom of the execution pane. The tab name indicates the time of the execution. Possible tabs are:

• On Event: The model is executed when the event occurs.

• On Exit: The model is executed after completion of the task/event.

• Decision: The model is executed when the process reached the gateway.

• Get Data: The model is executed when BPMN is waiting in a user task and returns the default values for the form.

For some elements the execution model must be created manually when you want to add execution, for others a default execution diagram is created automatically. Some BPMN elements allow for no execution at all.

If you want to learn more about execution models, refer to the chapter Modeling Execution and Modeling Tasks in the Designer Guide.

A form can contain several buttons. In case a button is clicked, something should happen. The developer needs to define, what should happen when a button is clicked. Therefore, he has to assign attribute Trigger Events in the attributes panel: It defines which button of a form associated to the element triggers the default process flow of a BPMN process.

Refer to Form - Process Interaction in the Designer Guide for more details.

Sometimes service models can become really big if you put all implementations into one big main model. The drawbacks are obvious: the bigger the model becomes, the longer it will take to load or compile the model. Additionally, if multiple modelers are working on the service, the Designer may slow down.

One solution is to use  Libraries  in this case (the other one is to build multiple smaller services). Using libraries, you can split your service implementation into smaller chunks that can be worked on independently. These chunks can be be reused in multiple services and tested separately. Libraries also speed up collaborative development because you can share your libraries with other developers.

If you want to learn more about the concept of libaries, refer to the chapters Working With Libraries and Developing an Using Libraries in the Designer Guide for more details.

The goal of your work in the Designer is an executable application. So once you have modeled your business process as a BPMN model, you need to add execution parts to bring the process to life. Processes are based on data that is going in, is processed, and coming out. This data is specified by data types. Data types can be structured into packages or interfaces. They are defined by classes and their properties, and have related operations and their parameters.

The execution diagram is the place where you make your model executable. Two steps are necessary to implement executional parts to your model:

1. You need to provide all necessary data types and operations. These types and operations reside in the  Service  panel.

2. In the second step, you need to select data types and operations from the Service panel, and add them to your process at the right places.

If you want to learn more about the concept of data modeling, refer to the chapters Modeling Data Structures and Concepts of Data Modeling in the Designer Guide. If you want to learn more about the execution diagram, refer to chapter Modeling Execution in the Designer Guide.

Data mapping is a very common task in the integration business: It is the process of connecting a data field from one source to a data field in another source. The Designer comes with a mapping editor that allows you to define attribute mappings directly in a mapping diagram by drawing relations between the properties of the involved classes.

Mapping diagrams are automatically created if you create a mapping operation on a class. The mapping diagram is based on the data model contained in the Implementation folder. It defines mappings between the data structures defined in this data model. You cannot change the data model in the mapping diagram, all attributes are read-only.

If you want to learn more about data mapping, refer to the chapters Modeling Data Mapping and Mapping Data Structures in the Designer Guide.

Each application offers two basic functionalities during execution: The user can start a process (and create a so-called process instance) and he can view the existing instances that have not yet been completed. These "instances in progress" are displayed in the instance list. For each BPMN model, a dedicated instance list is generated. During modeling, you can freely define which data should be displayed in the instance list.

Especially for role-based applications, not every user should have access to all instances. Therefore, the Designer also provides a role-based authorization concept for the instance list that allows you to define which user is authorized to see the instance list of the respective process.

If you want to learn more about the instance list, refer to the chapters Configuring the Instance List and Running Designer Applications in the Designer Guide.

Processes are based on data that is going in, is processed, and coming out. However, the application developer must determine which data can be accessed in which process step. Therefore, the execution diagram contains different sections:

• Message: Section  Message  is shown for all BPMN elements that need to process an incoming message.  As per default, the incoming message has type any . To gain access to the data used in your process, you have to apply the correct type from a customized library.

• Persisted: Variables created in section  Persisted  are usable in all executions of the BPMN model. They are "persisted" during the execution of the entire process.

• Local: Variables created in section  Local  are only available for use within the current execution. They are discarded when switching to the next process step.

Data that you want to be able to access throughout the process, you need to keep - this is the meaning of "persisting data".

If you want to learn more about how to persist data in the Designer, refer to Persisting Data in the Designer Guide.

For xUML services that have been deployed from the Designer as a container, secured endpoints are created automatically. However, these services are only usable internally and are not exposed to users outside the company. You have access to these endpoints via the service details in the PAS Administration. Refer to Controlling Containerized xUML Services (Docker) or Controlling Containerized xUML Services (Kubernetes) depending on your PAS setup.

If you want to make the APIs available to others, you can publish them via Scheer PAS API Management and restrict their usage with additional policies.
Refer to Exposing Designer Services via API Management in the API Management Guide for a detailed description.

Deploying a service is necessary to make it available to users. During development, a service is created and tested in a test environment. After successful testing, the service is deployed to the production system where it can be run by the appropriate user groups.

Especially in fusion teams, developers want to make a finished feature or an intermediate state of a service available to other team members for testing while they continue to work on the same service. This is easily possible in the Designer by using the test environment for developing, and deploying to the test server only when necessary. You only need to deploy your service if you want to allow other team members to test new features or if you want to run regeression tests against your test server.

For further details on testing and deploying, refer to Working with the Test Environment and Deploying a Service in the Designer Guide.

In role-based applications such as approval processes, roles are assigned to individual users. Each of these roles is associated with special rights. These decide which actions the respective user can perform, which data he or she can display and edit.

Roles are managed and assigned in the user management. Users of the Scheer PAS Designer are able to create them in the role editor. But only users authorized for user management can assign roles to specific users. Refer to Assigning Roles in the Designer Guide for details.

For more information about role management in the Scheer PAS User Management, refer to Managing Roles in the Administration Guide.

If you want to create analyses in Process Mining, you need to enable the analytics-collector-service in the PAS Administration first. By default, this service in disabled.

If you want to collect data from any service, you have to enable the scheduler as follows:

1. Open the service details in the Administration.

2. Go to tab Configuration and unlock it.

3. Set variable enable to true.

"collectorScheduler": {
    "enable": true,
   ...                }

You then need to enable the logging for the service you want to analyze. Refer to Collecting Logs for a detailed step-by-step instruction.

A common use case in the Designer is that multiple users want to work in a shared namespace. Namespaces are created and assigned in the Scheer PAS User Management. If you want to create a (shared) namespace, you must have permission for the user management.

Refer to Creating Shared Designer Namespaces for a detailed step-by-step instruction.

If users should be able to save their work within a Designer namespace, they need to have write permission on the namespace. Write permission is granted in Scheer PAS User Management.

Refer to Granting Write Permission for Namespaces for a detailed step-by-step instruction.

If you want to deploy your services to the integration component, you must create an additional user in the Bridge (with the same user name as in the user management). If the deployment to the integration component constantly fails, ask a user management administrator to check if you have a user in the Bridge on your system.

Refer to Managing Users in a Scheer PAS Environment in the Integration Platform User’s Guide for details.

Before you create your users, you should define a concept for standard / standard administration users: Clarify which user has to carry out which task. Then you can assign the necessary profiles.
Refer to Overview of Standard Profiles in the Administration Guide for explanations on all standard profiles and to which components they grant access.
Refer to Editing a User for detailed information on how to assign profiles to users.

For a standard Designer developer we recommend the following profile setup:

Use Case	Profile Name	Description	Related Documentation
Your user should be able to work within the Designer and deploy his services (which makes them executable).	pas_base	Grants access to the Scheer PAS Portal, the entry point of Scheer PAS. From this start page you can access all PAS components you are allowed to use.	Accessing the Scheer PAS Components
	pas_user	Grants access to Scheer PAS Designer where you can model your processes and execute them.	Getting Started with Designer
	xuml_container_admin	Grants limited access to the Scheer PAS Administration. Users with this profile are able to deploy their Designer services as container and can access the details of their own services within the administration.	Controlling Containerized xUML Services (Docker) Controlling Containerized xUML Services (Kubernetes) Controlling Integration Services
	integration_user	Grants access to the integration component (Bridge). If you want to deploy your services to the integration component, you must create an additional user in the Bridge (with the same user name as in the user management). We recommend using container deployment as the default deloyment target starting with PAS 23.1. For further information see: Designer Guide: Service Deployment Details Administration Guide: Controlling Containerized xUML Services (Docker) Controlling Containerized xUML Services (Kubernetes)	Integration User’s Guide Managing Users in a Scheer PAS Environment
	personal_sandbox	Each developer should get his own personal profile with namespace where he can develop on is own. Keep the personal sandbox private. For projects where several developers should collaborate, create shared profiles. Refer to Creating Shared Designer Namespaces for a step-by-step guide.	Managing Users Creating Shared Designer Namespaces

Maybe you have only read permission on the Designer service or on the folder the service resides in. Refer to Folders > Managing the Folder Permissions / Services > Managing the Service Permissions to find out how to check that.

If you have write permission on the folder and the service, ask a user management administrator to check if you have write permission on the namespace.
Refer to Editing a User > Granting Write Permission on Profiles in the Administration Guide for details.

Before you create your users, you should define a concept for standard / standard administration users: Clarify which user has to carry out which task. Then you can assign the necessary profiles.
Refer to Overview of Standard Profiles in the Administration Guide for explanations on all standard profiles and to which components they grant access.
Refer to Editing a User for detailed information on how to assign profiles to users.

The following profiles can be granted to an administrator:

Before you create your users, you should define a concept for standard / standard administration users: Clarify which user has to carry out which task. Then you can assign the necessary profiles.
Refer to Overview of Standard Profiles in the Administration Guide for explanations on all standard profiles and to which components they grant access.
Refer to Editing a User for detailed information on how to assign profiles to users.

If you user should only be able to execute a finished Designer application, he only needs a very basic profile setup:

Use Case	Profile Name	Description	Related Documentation
You user should be able to execute an application that has been created with the Designer.	pas_base	Grants access to the Scheer PAS Portal, the entry point of Scheer PAS. From this start page you can access all PAS components you are allowed to use.	Accessing the Scheer PAS Components
	your_sandbox	Assign the user the profile in which the application that he should be able to execute is stored. If the user should access a role-based application, assign him also the necessary role.	Running Designer Applications Running Role-based Applications Editing a User Managing Roles