Skip to content

Service task support in user interface #2349

@bjorntore

Description

@bjorntore

Description

This task is about creating frontend support for service tasks.

Service tasks are used to execute logic on the server that should be completed before the instance process continues.

We have implemented service tasks in such a way that when process next is called, and the process enters the service task, it's not immediately executed. The process is simply moved over to that task. Then, the next process next will cause the logic to execute. The reason we have done this is mostly due to error handling. If something fails while executing the service task, we want the process to be in that task, and allow for retrying, instead of it being stuck in the previous task.

However, we have also made it so that the next process next is automatically invoked server side, during the same request from the client/frontend, so from the clients perspective, the execution seems immediate. When all service tasks that have been chained after each other have been executed, the final process state is returned to the client.

Backend PR: Altinn/app-lib-dotnet#745
Backend branch: feat/pdf-service-task

Additional Information

Image

Example flow:

  1. Frontend is in a data task.
  2. Frontend calls process next and enters the first service task.
  3. The backend sees that we are in a service task, and automatically invokes process next again server side, without returning anything to the client yet. The service task logic is executed, and process moves to the next task.
  4. The next task is also a service task.
  5. The backend calls process next to execute the second service task, but it fails, and returns an error to frontend.
  6. Frontend can retry. If 'reject' path back to data task is added, that should work fine as well.

Tasks

  • Support service task in frontend. Do we just use normal layout-sets and let the TE configure it freely, with a good default?
  • Have ability to configure multiple tasks in the same PDF. Either via layout-set or via process task config.
  • IF service task doesn't have it's own layout set that can be rendered in a PDF, we need the capability to render previous tasks by visiting their URL.

Acceptance Criteria

  • Old PDF and eFormidling works just like before. Full backwards compatibility.
  • Can add a process task to render PDF of a number of tasks.
  • Can add process task to send eFormidling.
  • If a service task fails, the process current task is that service task, not another task.

Metadata

Metadata

Assignees

Labels

area/processkind/user-storyUsed for issues that describes functionality for our users.

Projects

Status

✅ Done

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions