Navigation :

Overriding Default Managed Objects

Overview

Atoti Sign-Off provides several objects out-of-the-box that are managed by the default EntityManager. Each of these objects is defined as a JPA entity using the @Entity and @Table annotations. The default entity classes are:

Managed Object	Entity Class
SignOff Process Definitions	`com.activeviam.signoff.workflow.model.definition.jpa.SignOffProcessDefinitionEntity`
SignOff Process Instances	`com.activeviam.signoff.workflow.model.instance.jpa.SignOffProcessInstanceEntity`
Adjustment Definitions	`com.activeviam.signoff.workflow.model.adjustment.definition.jpa.AdjustmentsDefinitionEntity`
Adjustment Executions	`com.activeviam.signoff.workflow.history.jpa.AdjustmentExecutionEntity`
Adjustment Definition History	`com.activeviam.signoff.workflow.history.jpa.AdjustmentDefinitionHistoryEntity`
Adjustment Execution History	`com.activeviam.signoff.workflow.history.jpa.AdjustmentExecutionHistoryEntity`

However, many of the default entity classes inherit fields from a parent class that is annotated with @MappedSuperclass. If you wish to modify a field inherited by one of the default entity classes, you need to override the parent class where that field is defined instead of the entity class. Be cautious when doing this, as any other entity classes inheriting from the same parent class will also be affected. The default @MappedSuperclass classes are:

Mapped Superclass	Inheriting Entity classes
Workflow Process Definitions	`com.activeviam.workflow.core.model.definition.jpa.AWorkflowProcessDefinitionEntity`
Process Instances	`com.activeviam.workflow.core.model.instance.jpa.AProcessInstanceEntity`
History Records	`com.activeviam.workflow.core.workflow.history.jpa.AHistoryRecordEntity`

In some scenarios, you may want to override the default managed objects, for example:

to change the length of a database column
to add new fields
to change a field’s attribute converter
to mark a field as nullable/not nullable
to add an attribute override
to add dynamic filters to entities at runtime

To customize these entities, you’ll need to override the default entity class that contains the fields affected. The following steps outline how to correctly configure your custom entity classes:

1. Copy the existing entity class to your project with the same class and package names

It is critical that the class and package names remain the same so that the EntityManager recognizes your custom entity class as an override of the default entity class and doesn’t treat it as a new entity. For example, to customize the description field of SignOffProcessDefinitionEntity class, you need to create a AWorkflowProcessDefinitionEntity.java file at the following path in your project:

./<java-folder>/com/activeviam/workflow/core/model/definition/jpa/AWorkflowProcessDefinitionEntity.java

Where <java-folder> is the path from the root of your project to the directory containing your .java files, typically src/main/java.

2. Modify the entity class as needed

warning

Removing or renaming existing fields may break Atoti Sign-Off.

You can now modify the entity class as needed. The following example doubles the length of the description field from the default of 4000 characters to 8000 and adds a new comment field with a length of 1000 characters, all other fields and methods remain unchanged:

Custom AWorkflowProcessDefinition.java

@MappedSuperclass
@Getter
@Setter
public abstract class AWorkflowProcessDefinitionEntity<E extends AWorkflowProcessDefinitionEntity<E>>
        extends ABitemporalObjectEntity<Long, E>
        implements IProcessDefinition<E>
{

    private static final long serialVersionUID = -4062921677920109539L;

    @Column(name="name", nullable=false)
    private String name;

    @Column(name="description", length = 8000)
    @Size(max=8000)
    private String description;

    @Column(name="comment", length = 1000)
    @Size(max=1000)
    private String comment;

    @Column(name="category")
    private String category;

    @Column(name="workflowType")
    private String workflowType;

    @Column(name="workflowProperties", length = 4000)
    @Convert(converter = ParametersConverter.class)
    @Size(max=4000)
    private Map<String, String> workflowParameters;

    @Column(name="serverName", length = 4000)
    @Size(max=4000)
    private String serverName;

    @Column(name="domain", length = 4000)
    @Size(max=4000)
    private String domain;

    @Column(name="filters", length = 4000)
    @Convert(converter = FiltersConverter.class)
    @Size(max=4000)
    private List<List<String>> filters;

    @Column(name="kpis", length = 4000)
    @Convert(converter = KpisConverter.class)
    @Size(max=4000)
    private List<String> kpis;

    @Override
    public String getKey() {
        return getKey(getName());
    }

    @Override
    protected void setKeys(String... keys) {
        name = keys[0];
    }

    @Override
    public int hashCode() {
        return Objects.hash(super.hashCode(), name, category, description, workflowType, workflowParameters, domain, filters, kpis);
    }

    @Override
    public boolean equals(Object obj) {
        return super.equals(obj)
                && Objects.equals(name, ((AWorkflowProcessDefinitionEntity<?>)obj).name)
                && Objects.equals(category, ((AWorkflowProcessDefinitionEntity<?>)obj).category)
                && Objects.equals(description, ((AWorkflowProcessDefinitionEntity<?>)obj).description)
                && Objects.equals(workflowType, ((AWorkflowProcessDefinitionEntity<?>)obj).workflowType)
                && Objects.equals(workflowParameters, ((AWorkflowProcessDefinitionEntity<?>)obj).workflowParameters)
                && Objects.equals(domain, ((AWorkflowProcessDefinitionEntity<?>)obj).domain)
                && Objects.equals(filters, ((AWorkflowProcessDefinitionEntity<?>)obj).filters)
                && Objects.equals(kpis, ((AWorkflowProcessDefinitionEntity<?>)obj).kpis);
    }

}

tip

If you have an existing database, and you modify the physical structure of the data in your schema, you may need to migrate the schema in order for your changes to take effect.

The next time you start Atoti Sign-Off, it will use your custom entity class for the SignOff Process Definition managed object. You can verify the change is applied by checking the schema for the processDefinition table in your database to verify that the description column has a length of 8000 and that the new comment column exists: Custom SignOff Table Schema