Skip to main content

Design Customizations

Variable Assistant​

Introduction​

Flowable Design has a variable assistant and an expression builder that is used to help modelers. This assistant allows modelers to have easy access (through auto complete) to the defined variables in the scope. In addition to that it also exposes different functions and beans that are available in the context. e.g. flwStringUtils (the Flowable String Utils) in BPMN / CMMN or flw in Forms / Pages.

There are 3 types of definitions:

  • Function definitions - These are definitions that are exposing the available FlowableFunctionDelegate(s)
  • Bean Definitions - The beans that are available in the context (e.g. flw in Forms / Pages and authenticatedUserId / flwStringUtils in BPMN / CMMN)
  • Type Definitions - The definitions of the different definition types

Expose through resources​

The definitions can be exposed by providing a json resource in a specific location. The resources need to be placed on the classpath in the com/flowable/design/expressions/custom folder and each have to end with a specific suffix.

  • Function definitions - file ending in .function.delegates.json e.g. myCustom.function.delegates.json. The JSON schema definition for this is located here
  • Bean definitions - file ending in .beans.json e.g. myCustom.beans.json. The JSON schema definition for this is located here
  • Type definitions - file ending in .types.json e.g. myCustom.types.json. The JSON schema definition for this is located here

App Publish Events​

Introduction​

In certain use cases, it's needed to execute custom logic when an app is published to a runtime system. The following section describes how this can be done.

Implementation​

Listening to app publish events can be done using an event listener implementation that looks similar to the event listener on the various Flowable engines.

An implementation in Java of the org.flowable.common.engine.api.delegate.event.FlowableEventListener needs to be added to the classpath as a Spring bean. There also is the org.flowable.common.engine.api.delegate.event.AbstractFlowableEventListener which has a default implementation for the transaction handling (which is only relevant in some very specific situations).

An implementation could look lik this:

public class CustomAppPublishListener extends AbstractFlowableEventListener {

    @Override
    public boolean isFailOnException() {
        return false;
    }
    
    @Override
    public Collection<? extends FlowableEventType> getTypes() {
        return Collections.singleton(DesignEventType.APP_PUBLISHED);
    }
    
    @Override
    public void onEvent(FlowableEvent event) {
        if (event instanceof AppPublishedEvent) {
            appPublished((AppPublishedEvent) event);
        }
    }
    
    protected void appPublished(AppPublishedEvent event) {
        // Write your custom logic with the event here
    }
}

Listening to the com.flowable.design.engine.api.event.DesignEventType.APP_PUBLISHED event will result in receiving an instance of com.flowable.design.engine.api.event.AppPublishedEvent which contains

  • The app model.
  • The content of the app in bytes.
  • The url to which this app is deployed to (which is useful when having multiple deployment targets configured).
  • Information about the app revision, which contains app key, app name, tenantId, workspaceKey, etc.

There also is the com.flowable.design.engine.api.event.DesignEventType.APP_REVISION_CREATED event type, which will result in an instance of com.flowable.design.engine.api.event.AppRevisionCreatedEvent. This event will be fired whenever a new revision is created in Design and contains the app model and the revision information.

Note that new app revisions can be created during app publishing, which means that you'll received both the events corresponding with the APP_REVISION_CREATED event and the APP_PUBLISHED.