v8

Overview of changes introduced in v8 of the Altinn.App.* packages

Why version 8

V8 is a rewrite of the process engine in apps to support more advanced process flows and signing. For most existing apps the changes to the process engine are only visible in the App/config/process/process.bpmn file.

We also took the opertunity to move alle interfaces from Altinn.App.Core.Interfaces to more description namespaces under Altinn.App.Core.Internal. Some of these interfaces have been renamed. For example has the Altinn.App.Core.Interfaces.IData has been moved and renamed to: Altinn.App.Core.Internal.Data.IDataClient

Breaking changes

Changes in process.bpmn

altinn namespace changed

Previously the name space altinn was http://altinn.no this has now been changed to http://altinn.no/process

This is located in the top of the process.bpmn file.

Old process.bpmn:

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions id="Altinn_SingleDataTask_Process_Definition"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:altinn="http://altinn.no"
xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
targetNamespace="http://bpmn.io/schema/bpmn" >
....
</bpmn:definitions>

New process.bpmn:

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions id="Altinn_SingleDataTask_Process_Definition"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:altinn="http://altinn.no/process"
xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
targetNamespace="http://bpmn.io/schema/bpmn" >
....
</bpmn:definitions>

TaskType definition moved to bpmn:extensionElements

Up until v8 of the nuget taskType was defined direcly on the <bpmn:task> element. To adhere more to the bpmn specification this has been moved to <bpmn:extensionElements> element.

<bpmn:task id="Task_1" name="Utfylling" altinn:tasktype="data">
    <bpmn:incoming>Flow1</bpmn:incoming>
    <bpmn:outgoing>Flow2</bpmn:outgoing>
</bpmn:task>

<bpmn:task id="Task1" name="Utfylling">
    <bpmn:incoming>Flow1</bpmn:incoming>
    <bpmn:outgoing>Flow2</bpmn:outgoing>
    <bpmn:extensionElements>
        <altinn:taskExtension>
            <altinn:taskType>data</altinn:taskType>
        </altinn:taskExtension>
    </bpmn:extensionElements>
</bpmn:task>

This looks and is more verbose, but as we need to specify more options for signing we opted to move all our custom configuration into the same section.

Confirmation tasks needs to define action confirm

Previously confirms tasks implicitly added a confirm aciton for the user (enabling the Confirm button in the UI) With the introduction of actions on process tasks the developer needs to define the aciton confirm on confirmation tasks

Old confirmation task:

<bpmn:task id="Task_1" name="Utfylling" altinn:tasktype="confirmation">
    <bpmn:incoming>Flow1</bpmn:incoming>
    <bpmn:outgoing>Flow2</bpmn:outgoing>
</bpmn:task>

New confirmation task:

<bpmn:task id="Task1" name="Utfylling">
    <bpmn:incoming>Flow1</bpmn:incoming>
    <bpmn:outgoing>Flow2</bpmn:outgoing>
    <bpmn:extensionElements>
        <altinn:taskExtension>
            <altinn:taskType>confirmation</altinn:taskType>
            <altinn:actions>
                <altinn:action>confirm</altinn:action>
            </altinn:actions>
        </altinn:taskExtension>
    </bpmn:extensionElements>
</bpmn:task>

New dotnet version

The solution has been updated to use the newest LTS version of dotnet, .NET 8.0 This needs to be updated in the project file and in the Dockerfile.

Old Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS build
WORKDIR /App

COPY /App/App.csproj .
RUN dotnet restore App.csproj

COPY /App .

RUN dotnet publish App.csproj --configuration Release --output /app_output

FROM mcr.microsoft.com/dotnet/aspnet:6.0-alpine AS final
EXPOSE 5005
WORKDIR /App

New Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS build
WORKDIR /App

COPY /App/App.csproj .
RUN dotnet restore App.csproj

COPY /App .

RUN dotnet publish App.csproj --configuration Release --output /app_output

FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS final
EXPOSE 5005
WORKDIR /App

For a complete view of the changes in Dockerfile, see diff on github.

Changes to interfaces for clients and services

Clients and services we provide to communicate with the core services we provide like storage and secrets have been moved and rename to make it more clearly what they interact with.

Moved/Renamed interfaces and their new location

All the old interfaces are marked as Obsolete and will generate compiletime errors with reference to what interface you should use in its place.

Whats new

Support for signing tasks

V8 support defining signing tasks in the process definition. v8.0.0 supports sequential signing steps with the possibility to define that signing tasks needs to be completed by unique users. To see how signing tasks are define please see the signing documentation under process

Support for expressions in process definition

Its now possible to make process flow decisions using expressions in the process definition. To see how you can leverage expressions to dictate process flow see using expressions to dictate process flow

Custom process actions

Custom actions makes it possible to create custom actions for moving the process along. These actions can be authorized separatly, used in expressions inside the process definition to change how the process flows and execute custom code before the process is moved to the next task. To see how you can use custom process actions see defining custom actions in process tasks

Custom server actions

Custom server actions makes it possible to create custom actions that can be executed from the UI without moving the process. These actions can be authorized separatly and execute custom code. To see how you can use custom server actions see defining custom actions in process tasks