Runtime 2020.12 The standard header handling of the xUML Runtime as described above works well in homogeneous xUML environments. If you need to access services that are implemented using other technologies (e.g. in a distributed environment), however, the standard HTTP header handling may not meet your needs. You may need to e.g. provide correlation IDs in a different header, or overwrite standard header names. With the concept of HTTP Header Roles, you can take control of the header handling by defining your own header roles. Once you define header roles, the standard header handling will be completely dropped and replaced by your configuration. |
Once header roles are defined, they are changeable as settings on the Bridge (see xUML Service Settings). Configuring Incoming Header Roles on HTTP ServicesFor all services that are accessible via the HTTP protocol (HTTP, REST, SOAP), you can define your own pairs of <http header name>:<role> in the component diagram in tagged value httpHeaderRoles on the composite (<<E2EComposite>>). httpHeaderRoles can hold a list of definitions in format <http header name>:<role> (one list entry per line). See Frontend Components for more details on component diagrams. This can be used to overwrite the default behavior for HTTP services described above. Available roles are: Role | Description |
---|
none | Remove the role from a standard header with e.g. X-Transaction-Id:none . | client_host | The header identified by <http header name> should be treated as X-Sender-Host. | client_service | The header identified by <http header name> should be treated as X-Sender-Service. | correlation_id | The header identified by <http header name> should be treated as X-Request-Id. | transaction_id | The header identified by <http header name> should be treated as X-Transaction-Id. | The following rules apply to the usage of header roles: - The default header handling is completely dropped and replaced by your definitions (see example 2).
If you want to use the standard configuration and just exchange one header configuration, you must reconfigure the other standard headers. - You can assign multiple roles to the same header by listing the header twice in the role definition (see example 5).
- If you apply the same role to different headers, the first one (in order of definition) is used (see example 4).
Some examples: Nr | Role Definition on Service Composite | Incoming Headers | Headers Regarded by Runtime | Rules Applied |
---|
1 |
| X-Sender-Host X-Sender-Service X-Request-Id X-Transaction-Id | X-Sender-Host X-Sender-Service X-Request-Id X-Transaction-Id
| | 2 | myHeader=client_host | X-Sender-Host X-Sender-Service X-Request-Id X-Transaction-Id |
| - role definition overwrites standard handling,
standard headers are disregarded
| myHeader X-Sender-Host X-Sender-Service X-Request-Id X-Transaction-Id | myHeader | - role definition overwrites standard handling,
standard headers are disregarded - incoming user-defined header is regarded
| 3
| myHeader=client_host X-Sender-Service=client_service X-Request-Id=correlation_id X-Transaction-Id=transaction_id | X-Sender-Host X-Sender-Service X-Request-Id X-Transaction-Id | X-Sender-Service X-Request-Id X-Transaction-Id | - role definition overwrites standard handling
- only the redefined standard headers are regarded
| myHeader X-Sender-Host X-Sender-Service X-Request-Id X-Transaction-Id | myHeader X-Sender-Service X-Request-Id X-Transaction-Id | - role definition overwrites standard handling
- redefined standard headers are regarded
- incoming user-defined header is regarded
| 4 | myHeader2=correlation_id myHeader1=correlation_id
| myHeader1 myHeader2 | myHeader2 | - myHeader2 takes precedence over myHeader1 because it comes first in order of definition
| myHeader1 | myHeader1 | - myHeader1 is regarded because myHeader2 has not been provided
| 5 | myHeader=correlation_id myHeader=transaction_id | myHeader | myHeader | - contents of myHeader are treated as correlation and transaction id
| Incoming Header Roles on REST ServicesAdditionally, header roles of REST services can be overwritten in the <<E2ERESTService>> definition (same rules as explained above). When specifying roles on both, the composite and the REST service, please note that header role definitions on the REST service (<<E2ERESTService>>) overrule the same role definitions on the composite(<<E2EComposite>>). |
Some examples: Example 3 does not behave as documented here. The xUML Runtime will prefer myHeader1 to myHeader2 if both headers are provided. This issue will be fixed with one of the next Runtime releases. |
Nr | Role Definition on Service Composite | Role Definition on REST Service | Incoming Headers | Headers Regarded by Runtime |
---|
1 |
|
| X-Sender-Host X-Sender-Service X-Request-Id X-Transaction-Id | X-Sender-Host | sender host | X-Sender-Service | sender service | X-Request-Id | request/correlation id | X-Transaction-Id | transaction id | 2 | myHeader=client_host |
| myHeader X-Sender-Host X-Sender-Service X-Request-Id X-Transaction-Id | myHeader | sender host | 3 | myHeader1=client_host | myHeader2=client_host | myHeader1 myHeader2 | myHeader2 | sender host | myHeader1 | myHeader1 | sender host | 4
| myHeader1=client_host myHeader2=client_service | myHeader2=client_host | myHeader1 myHeader2 | myHeader2 | sender host | 5 | myHeader1=client_host myHeader2=client_service | myHeader2=none | myHeader1 myHeader2 | myHeader1 | sender host | 6 | myHeader1=client_host | myHeader2=client_service | myHeader1 myHeader2 | myHeader2 | sender service | myHeader1 | sender host | 7 | myHeader2=correlation_id myHeader1=correlation_id |
| myHeader1 myHeader2 | myHeader2 | request/correlation id | 8 | myHeader2=correlation_id myHeader1=correlation_id | myHeader1=correlation_id | myHeader1 myHeader2 | myHeader1 | request/correlation id | |