Developing with Designer from Version 23.1
With PAS 23.1, the development process in the Designer has been optimized. To speed up and simplify the development process, we have decoupled development from deployment: Developers now work in a test environment where they can get constant feedback on their changes and can test them directly against the service preview.
The new approach also improves the work of fusion teams on a microservice: Developers can now make a finished feature or an intermediate state of a service available to other team members for testing while continuing to work independently on the same service.
Your benefits:
You can access a preview of your service without having to deploy it, which speeds up testing and process optimization.
Your test service is constantly compiled and validated. Errors and warnings are displayed in the validation panel and help you create a flawless service.
You only need to deploy your service...
if you want to give other team members the opportunity to test dedicated features or versions of the service.
if you want to run regeression tests against your test server.
In the meantime, you continue to develop the service independently of the deployed version.
New: Test Environment
When you create a new service or open an existing one, you are automatically working in the test environment. Its status is displayed in the Controls panel:
The test environment is automatically started and stopped:
It is started...
when you open a service and start working on it.
when you select option Open test application.
when you trigger a manual validation via option Start validation.
It is stopped...
when you have not worked on your service for a certain amount of time. Default setting is 2 hours.
when the corresponding project is deleted.
Status Message | Description |
|---|---|
 | The test environment has not yet been started or has expired. |
 | The Designer is preparing the test environment. |
 | The test environment is ready. You can access the application preview. |
Using the Test Environment
The test environment is initialized automatically when you start working on a service. As soon as you make changes in the Designer, the test environment is updated to reflect your changes. In addition, your actions are constantly compiled and validated. Compilation errors are displayed in the validation panel. Check the panel for errors and warnings to resolve any problems that occur in your service. Refer to Validation Panel in the Designer Guide for details.
You can disable the auto validation, refer to Service Configuration Details in the Designer Guide for further information.
The new Controls panel contains options to support you during the development process:
Icon | Description |
|---|---|
 | Use this icon to trigger the validation manually. |
 | Use this icon to open the Log Analyzer and access the logs. You have the choice between service and application logs.
Refer to Administration Guide > Analyzing Platform Logs for further information about the Log Analyzer. |
 | The option Clear Compiler cache is now directly available via an icon in the controls panel. Clearing the Compiler cache is helpful if the validation panel shows errors you cannot solve. Using this option reinitializes the test environment. |
 | Use this icon to open a preview of your service. |
 | Use this icon to open the additional menu of the controls panel which gives you access to further options (refer to Designer Guide > Controls Panel for details). |
Using the Service Preview
Accessing the test service is possible without deployment. Open the service preview via the controls panel and the service start page will open in a new tab:
You have direct access to your service(s):
Icon | Description |
|---|---|
 | Start your process and create a new instance. |
 | Open the instance overview to inspect running instances. |
The preview is fully operational. Use it to check functionality, layout and design of your process and its forms:
Deploying the Service
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 now easily possible in the Designer: Just deploy the version you want to make available to others and continue working on the service independently in the test environment.
The Deployment Controls have been moved to the service details page. Click on the Service panel tab (service name) to open the details page:
Select your deployment target the first time you deploy. Use the target switch in section Options to select your desired deployment target:
Prerequisites
Container deployment: Your user must be assigned the xuml_container_admin profile.
Integration (Bridge) deployment: Your user must be assigned the integration_user profile and he must have an integration user account created by an integration administrator.
Refer to Overview of Standard Profiles in the Administration Guide.
We recommend to enter a version number and increase the number with each deployment:
Expert Advice
By default, each newly created service gets number 0.1.0 assigned. We recommend to increase the version number before redeploying each time you have made relevant changes to the service. You can change the version number in section General of the Deployment Properties. Follow the concept of semantic versioning.
In case of deployment problems, comparing the version number and the number of the deployed version can help to find out which version of the service is running.
Now use the deployment controls to deploy the service to your chosen target:
Button | Description |
|---|---|
 | Use this option to deploy the service to the selected deployment target. |
 | Use this option to open the application of the deployed service in a new browser tab. If this button is greyed out, the service has not been deployed yet. |
 | Use this option to open the deployed service in the management UI of the selected deployment target:
If this button is greyed out, the service has not been deployed yet. |
 | Use this option to open the test UI of the service API. If this button is greyed out, the service has not been deployed yet. |
 | Use this option to access the service logs of the deployed xUML service in the Log Analyzer. Refer to Analyzing Platform Logs in the Administration Guide for more information about the Log Analyzer. If this button is greyed out, the service has not been deployed yet. |
Executing the Service
The deployed service is accessible via option Open Application in the deployment controls section. The start page of the deployed service looks exactly the same as that of the test service:
The handling of the deployed service is also the same:
Users can create new instances and execute the process.
Users can access the instance overview.
The difference is: The deployed version does not change, even if the developer changes the service in the test environment.
Example: Test Service vs. Deployed Service
A developer created a simple test application, containing only a user task with an assigned test form:
The test form contains two input fields and a button:
The developer deploys this version:
After the deployment of this version, he starts to extend the test form:
Test Service
The developer opens the test service:
The developer starts the process to create a new instance:
The adapted form opens:
Deployed Service
The tester opens the deployed service:
The tester starts the process to create a new instance:
The deployed version of the form opens:
Related Documentation: