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.

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.