Studio Developer Manual / Version 2406.0
Table Of ContentsThis section describes the most basic steps to make new workflows known to Studio.
Studio server and User Changes App
For the Studio server, two basic customizations are possible.
Defining the Workflow Category
You have to define the process category of your workflow, either localization or publication. You have two ways to do so:
Let the name of your workflow definition contain either
Translation
orPublication
.Add the name of your new workflow definition to the
translationProcessNames
orpublicationProcessNames
beans for the corresponding workflow category. Example 9.102, “Add a new workflow with the name StudioThreeStepPublication to publicationProcessNames ” shows this for a new 3-step publication workflow.@Bean @Customize("publicationProcessNames") List<String> addThreeStepPublicationWorkflowName() { return List.of("StudioThreeStepPublication"); }
Example 9.102. Add a new workflow with the name StudioThreeStepPublication to publicationProcessNames
Enabling Notifications for Tasks
You can switch on Studio notifications for tasks of your new workflow when they appear in the Control Room or Workflow App inbox. You do this via a Spring Java configuration in the application context of the Spring Boot app that acts as the User Changes application. This can be the Studio server app itself (for example, in the in-memory setup), but typically it is the dedicated User Changes app.
Customize the beans notificationsForTranslationWorkflowList
or notificationsForPublicationWorkflowList
for a translation or publication workflow, respectively.
Example 9.103, “Enable notifications for new StudioThreeStepPublication workflow
” shows this for a new 3-step publication workflow.
@Bean @Customize("notificationsForPublicationWorkflowList") List<String> addThreeStepPublicationWorkflowNotifications() { return List.of("StudioThreeStepPublication"); }
Example 9.103. Enable notifications for new StudioThreeStepPublication workflow
Studio client
For the Studio client it is important to note that both the Main App and the Workflow App need to be taken into consideration. For the time being, workflows are still started in the Control Room of the Main App, but running workflows can only be displayed in the Workflow App. However, it is typically sufficient to develop one shared module for a workflow customization and add it as a dependency to both client apps (see Section 9.1, “General Remarks On Customizing (Multiple) Studio Apps”).
Customizing workflows for the Studio client involves no Ext JS, so no StudioPlugin
or StudioStartupPlugin
is needed. Instead, an autoLoad
entry for the custom workflow module
is the way to go (see Section “Customization Entry points”).
In the auto-loaded script, the global constant workflowPlugins
is used to add workflow plugins.
In the example below, a translation workflow is added. A corresponding method addPublicationWorkflow
also exists.
workflowPlugins._.addTranslationWorkflowPlugin({ workflowName: "MyCustomTranslation", });
Example 9.104. Minimal Studio client enabling of a custom translation workflow
This is the minimal configuration needed to make a custom workflow known to the Studio client.
In the example, addTranslationWorkflowPlugin
is implicitly called with any
for the
model type parameter. A specific type will be needed
once additional workflow form fields are configured (see below).