CaseFabric Reference Guide

CaseFabric Reference Guide

  • Overview
  • Getting Started
  • CMMN
  • CaseFabric IDE
  • CaseFabric Engine
  • Extensions
  • API Reference
  • Releases

›Releases

Overview

  • CaseFabric
  • A short introduction
  • Product Overview

Getting Started

  • Introducing CaseFabric Demo
  • Generic UI
  • How to use task UI rendering
  • Two business applications
  • Obtaining CaseFabric Demo

Some CMMN

  • What is CMMN
  • Modelling the Case Plan
  • Modelling the Case File
  • Modelling the Case Team
  • Other things to model

CaseFabric IDE

  • An IDE?
  • Designing
  • Tasks and Parameters
  • Expressions
  • Deploying
  • Debugging

CaseFabric Engine

  • The CaseFabric Engine
  • Authentication
  • Authorization
  • Pictorial overview
  • Configuration
  • Logging
  • Repository

Extensions

  • Do we need extensions?
  • Fault Handling
  • Workflow
  • Business Identifiers

API Reference

  • Introducing the API
  • Joining the platform
  • Start a Case
  • Case Team membership
  • Executing the case
  • Retrieving cases and tasks
  • Casefile requests

Releases

  • Overview
  • 1.1.34
  • 1.1.33
  • 1.1.32
  • 1.1.31
  • 1.1.30
  • 1.1.29
  • 1.1.28
  • 1.1.27
  • 1.1.26
  • 1.1.25
  • 1.1.24
  • 1.1.23
  • 1.1.22
  • 1.1.21
  • 1.1.20
  • 1.1.19
  • 1.1.18
  • 1.1.17
  • 1.1.16
  • 1.1.15
  • 1.1.14
  • 1.1.13
  • 1.1.12
  • 1.1.11
  • 1.1.10
  • 1.1.9
  • 1.1.8
  • 1.1.7
  • 1.1.6
  • 1.1.5
  • 1.1.4
  • 1.1.3
  • 1.1.2
  • 1.1.1
  • 1.1.0

Cafienne Engine Release 1.1.28

Model driven fault handling

The CMMN 1.1 specification provides for an excellent language to model case proceedings. This includes very natural ways of starting, stopping, suspending and resuming tasks - even to the extent of handling failures.
The unfortunate thing is that influencing this from a modeling perspective is limited to starting and stopping tasks. With this release of Cafienne, the modeling is extended for dealing with failure situations in a more intuitive manner. Furthermore this release contains fixes for dealing with security and performance challenges.

A detailed description of this functionality can be found in CMMN Fault Handling Extensions.

Improved SQL Server performance

Microsoft SQL Server is a well known and well established database in the market. It can also be configured as a persistence layer for the Cafienne event journal.
The JDBC drivers of Microsoft have a somewhat peculiar style of converting Java Unicode strings to varchar and nvarchar database columns. This leads to full table scans during the insertion of new events to the journal, which drastically slows down the system when it grows.
In this release, the database schema of SQL server for storing events is adjusted to only contain varchar columns, and no more nvarchar columns.
Furthermore it is highly recommended to adjust the SQL Server connection string for the event journal as described in the configuration page.

More dynamic Human Tasks

Cafienne Engine treats Human Tasks as "thin" as possible.
The default test user interface that ships with the getting-started environment makes use of JSON Schema for rendering task contents.
The task definition can hold this schema in a custom property called task-model. The content of the task-model is treated as a string by the engine, that is simply passed through.

From this release onwards, the task model can be dynamically adapted based on SPEL expressions detected inside the task-model string, in a manner similar to the HTTP call definitions.

Housekeeping

This release holds a few dependency updates resolving security issues.
Furthermore internal refactoring took place to reduce and simplify the engine code, making it better maintainable.
Also some deeper issues have been found & fixed.

Tickets closed

TicketDescription
#397When a stage is suspended, and it has a HumanTask in available state, there should not be a HumanTaskSuspended event
#398When a subcase fails, the CaseTask should reactivate instead of start
#399Akka journal with JDBC string conversion on MS SQLServer generates non-performant queries
#401It should be possible to use HumanTask input parameters in the task-model definition
#406Deleting tenant should also clear the query data on consent groups
#407Deleting tenant should not be allowed if groups are in use in cases of other tenants
#408Case team group removal can lead to null pointer exceptions
#413Consent group member roles in the case team without case roles cannot access a case
#414Case archival and deletion should be allowed only for case owners
← 1.1.291.1.27 →
  • Improved SQL Server performance
  • More dynamic Human Tasks
  • Housekeeping
  • Tickets closed