You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 17293fc
Browse filesBrowse the repository at this point in the historyBrowse files
[ActivityDefinition](../fhir/activitydefinition.md), [Understanding the Process Authorization Extension](./understanding-the-process-authorization-extension.md)
title: Understanding the Process Authorization Extension
3
+
icon: creative
4
+
---
5
+
6
+
The authorization rules live inside a `<extension url="http://dsf.dev/fhir/StructureDefinition/extension-process-authorization">` block in the `ActivityDefinition`.
7
+
8
+
```xml
9
+
<!-- The outermost container for one complete authorization rule block.
10
+
One block covers exactly one message name, one Task profile, and the
11
+
requester/recipient rules for it.
12
+
Add a second block if you have a second message type. -->
When access needs to be restricted to a **specific organization** or a **specific OIDC role**, a nested `<extension>` inside `<valueCoding>` has to be added to narrow the rule further:
55
+
56
+
```xml
57
+
<!-- Example: only a specific remote organization may send -->
58
+
<extensionurl="requester">
59
+
<valueCoding>
60
+
<!-- Narrow down: which specific organization? -->
> **Reading tip:** The outer `<code>` can be thought of as the *category* of the rule (e.g. "a local client with a specific role") and the inner `<extension>` as the *precise value* within that category (e.g. "the role `DSF_ADMIN`"). Both are needed together.
93
+
94
+
## Related Topics
95
+
[ActivityDefinition](../fhir/activitydefinition.md), [Creating ActivityDefinitions](../guides/creating-activity-definitions.md), [Requester and Recipient Examples](./requester-and-recipient.md)
Copy file name to clipboardExpand all lines: docs/src/process-development/api-v2/guides/creating-activity-definitions.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -757,4 +757,4 @@ All other elements can technically be omitted. Still, the following elements are
757
757
</details>
758
758
759
759
## Related Topics
760
-
[ActivityDefinition](../fhir/activitydefinition.md), [Creating CodeSystems for DSF Processes](creating-codesystems-for-dsf-processes.md), [Creating ValueSets for DSF Processes](creating-valuesets-for-dsf-processes.md), [Task](../fhir/task.md)
760
+
[ActivityDefinition](../fhir/activitydefinition.md), [Creating CodeSystems for DSF Processes](creating-codesystems-for-dsf-processes.md), [Creating ValueSets for DSF Processes](creating-valuesets-for-dsf-processes.md), [Requester and Recipient Examples](../dsf/requester-and-recipient.md), [Task](../fhir/task.md), [Understanding the Process Authorization Extension](../dsf/understanding-the-process-authorization-extension.md)
- Validates actual `Task.input.type.coding.system` and `Task.input.type.coding.code` pairs against fixed constraints declared in the referenced `StructureDefinition` slices
694
+
- Validation direction is **Task → StructureDefinition** (actual instance values are checked against allowed fixed pairs)
695
+
-**System mismatch for existing code**:
696
+
- If a Task input code exists in SD constraints, but with a different system
697
+
- Error: `FHIR_TASK_INPUT_FIXED_URI_MISMATCH`
698
+
-**Code mismatch for existing system**:
699
+
- If a Task input system exists in SD constraints, but with a different code
700
+
- Error: `FHIR_TASK_INPUT_FIXED_CODE_MISMATCH`
701
+
-**Pair not allowed by SD constraints**:
702
+
- If a non-BPMN Task input `(system, code)` pair is not defined by any SD `fixedUri/fixedCode` constraint
703
+
- Error: `FHIR_TASK_INPUT_PAIR_NOT_ALLOWED_BY_SD`
704
+
-**Validation Behavior**:
705
+
- Check runs only when profile can be resolved and fixed constraints are extractable from the referenced `StructureDefinition`
706
+
- BPMN message inputs (`http://dsf.dev/fhir/CodeSystem/bpmn-message`) are excluded from this specific pair-not-allowed check because they are validated in dedicated Task input rules
707
+
644
708
645
709
#### StructureDefinition Resources
646
710
@@ -702,6 +766,24 @@ According to FHIR profiling specification §5.1.0.14:
702
766
- No individual slice's maximum cardinality may exceed base element's maximum
// Every class referenced via camunda:class in the BPMN must have
1148
+
// a corresponding @Bean here (or in another registered @Configuration).
1149
+
@Bean
1150
+
publicSelectDicTargetsselectDicTargets() {
1151
+
returnnewSelectDicTargets(api);
1152
+
}
1153
+
1154
+
@Bean
1155
+
publicSelectDmsTargetselectDmsTarget() {
1156
+
returnnewSelectDmsTarget(api);
1157
+
}
1158
+
}
1159
+
```
1160
+
#### Spring Bean Scope (`SpringConfigurationLinter`)
1161
+
1162
+
In Camunda and the Data Sharing Framework (DSF), Spring beans that act as delegates, execution listeners, or task listeners should usually be configured with **prototype** scope (`SCOPE_PROTOTYPE`). If the `@Scope` annotation is omitted, Spring defaults to **singleton**. That can be acceptable for strictly stateless classes; as soon as someone adds mutable instance state, the risk of race conditions and hard-to-debug concurrency bugs rises sharply—often only visible under load.
1163
+
1164
+
After a BPMN-referenced class is **covered** by a `@Bean` in a registered `@Configuration` (see [Spring Configuration Registration](#spring-configuration-registration)), the linter inspects the covering `@Bean` method for `@Scope` and the referenced implementation class for **mutable** instance fields (not `static`, not `final`). Emitted rules:
1165
+
1166
+
-**Success** – `SPRING_BEAN_SCOPE_PROTOTYPE`: `@Scope` is **prototype** (e.g. `ConfigurableBeanFactory.SCOPE_PROTOTYPE` or `@Scope("prototype")`). No further scope items for that reference in this pass.
1167
+
-**Error** – `SPRING_BEAN_SCOPE_MUTABLE_SINGLETON`: The bean is **effectively singleton** (missing `@Scope`*or* explicit non-prototype scope such as `singleton`) **and** the referenced class has **mutable** instance fields. Emitted **once** per reference before the following warnings.
1168
+
-**Warning** – `SPRING_BEAN_SCOPE_MISSING`: The covering `@Bean` has **no**`@Scope` (Spring’s default is singleton, which is risky for Camunda hooks unless the implementation is provably stateless).
1169
+
-**Warning** – `SPRING_BEAN_SCOPE_SINGLETON_EXPLICIT`: `@Scope` is **explicitly** set to a **non-prototype** value (typically `singleton`); the developer should verify that the delegate or listener is safe to share across process instances.
1170
+
1171
+
**Why this matters:** The rule stays aligned with DSF wiring (only configurations from `getSpringConfigurations()`) and surfaces dangerous combinations—singleton or default-singleton scope plus mutable instance state—before they appear in production.
1172
+
1173
+
**Example scenarios**
1174
+
1175
+
*Missing `@Scope` → warning (and error if the delegate/listener class has mutable instance fields)*
0 commit comments