FAQ: Designer

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.

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

• OData 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.

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.

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.

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.

In processes that contain a form with a data table, you can use the click action of a user on a data table row as a trigger event for user tasks and boundary events. This works similar to a button trigger event and causes the process flow to continue with the next step. Refer to Handling the Click Event of Data Table Rows for detailed information.

Have a look into our PAS Modeling Guidelines. They help you to better organize, develop, and document your Designer project. The guidelines contain information on project organization and project documentation, tips for naming conventions, and helpful information on how to handle custom settings, mappings, logging, and error handling.

Another helpful chapter is Drawing a Business Process where you can find details about

• Modeling Process Start

• Modeling Process End

• Modeling Tasks

• Modeling Decisions

• Modeling Message Reception

• Using Forms

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.

Only two default fields are displayed in each instance table: Current Task, displaying the name of the task in which the instance is currently located, and Instance Id, displaying the automatically generated identifier of the instance. You must add any other content you want to display in the list yourself. Please note: The instance list can only show one value per field. Refer to Configuring the Columns of the Instance List for details.

If you want to display data from your form fields to the instance list, you first need to make sure that this data is persisted within the process, meaning: Each variable you want to display in your instance list must be individually available in the Persisted section of your execution diagram. Refer to Modeling Execution and Displaying Custom Data in the Instance List for further information.

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.

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. One solution is to use Libraries in this case.

If you want to develop your own libraries, the following pages may be helpful to you:

• Developing and Using Libraries

• Versioning of Libraries

• Sharing Designer Content

Versioning is the process of assigning a unique version number to a unique state of your service. And versioning is an important topic to consider when you develop services in the Designer. Refer to Versioning of Services for detailed explanations and tips how to version your xUML services.

Elements can have default values and/or options to select from. These can be specified in the Attributes panel as described on the documentation pages of the respective form element.
There may be cases, however, where values of form elements need to be set dynamically at service runtime. Doing this is possible for all form elements. Refer to Setting Form Elements Dynamically for detailed information.

Yes. You can style your PAS installation and your developed PAS applications using CSS. To do this, you need a CSS file that contains the related styling definitions. Refer to Styling Forms With CSS 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.

When modeling xUML services with the Designer, you may come to a point where the features of BPMN and xUML are not sufficient for your purposes. For these cases, the Designer comes with an Action Script Language that implements the action semantics for UML.

The action script language supports the following language elements:

• create statements

• set and append statements (optionally with a guard)

• object navigation

• arithmetic and boolean expressions

• operation calls

• second order operations such as apply, reduce and select for arrays

We recommend to not use suboperations in Action Script. In case they are moved to a different location, the path to the operation changes and you need to change all Action Script statements.

Refer to chapter Action Script Language and Using Action Script for more detailed information.

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.