Lookup Pattern - Revision history

Ictu harold.metselaar: /* Application Collaborations */

2022-05-02T13:58:21Z

Application Collaborations

Ictu harold.metselaar: /* Process Realisation of the Evidence Lookup */

2022-04-04T12:30:53Z

Process Realisation of the Evidence Lookup

Ictu harold.metselaar: /* Process Realisation of the Evidence Lookup */

2021-08-24T14:52:30Z

Process Realisation of the Evidence Lookup

Ictu harold.metselaar: /* Process Realisation of the Evidence Lookup */

2021-08-24T14:51:56Z

Process Realisation of the Evidence Lookup

Ictu mavi.cristache at 09:58, 1 July 2021

2021-07-01T09:58:13Z

Ictu mavi.cristache: typos after migration to doc

2021-06-29T20:27:46Z

typos after migration to doc

Show changes

Ictu mavi.cristache: /* Business Process of the Evidence Lookup */

2021-06-29T20:17:18Z

Business Process of the Evidence Lookup

Ictu mavi.cristache: /* Process Realisation of the Evidence Lookup */ missing captions

2021-06-29T20:16:33Z

Process Realisation of the Evidence Lookup: missing captions

Ictu mavi.cristache at 19:42, 29 June 2021

2021-06-29T19:42:59Z

Ictu mavi.cristache at 19:42, 29 June 2021

2021-06-29T19:42:42Z

← Older revision		Revision as of 13:58, 2 May 2022
Line 207:		Line 207:

	The Evidence request is received via [[Data Logistics]] and with the help of [[Trust Architecture]] the DP checks the signature of the request and decrypts it. An Authority check may be performed using the [[Information Desk]] establishing that the DC is allowed to request the evidence type, which is most likely not in scope of the pilot with a limited number of participants. Next the subject identity is established using [[Trust Architecture]]. If successful, the evidence is extracted by [[Evidence Retrieval]] Retrieval and transformed to canonical form ([[Evidence Portal]]). Various exceptions like non-availability of OOP or the delay or non-availability of evidence are handled by [[Evidence Portal]] and [[Data Logistics]] . If all is well , the Evidence response is composed and prepared for transfer ([[Evidence Portal]]), encrypted and digitally signed using [[Trust Architecture]] and ultimately exchanged using [[Data Logistics]].		The Evidence request is received via [[Data Logistics]] and with the help of [[Trust Architecture]] the DP checks the signature of the request and decrypts it. An Authority check may be performed using the [[Information Desk]] establishing that the DC is allowed to request the evidence type, which is most likely not in scope of the pilot with a limited number of participants. Next the subject identity is established using [[Trust Architecture]]. If successful, the evidence is extracted by [[Evidence Retrieval]] Retrieval and transformed to canonical form ([[Evidence Portal]]). Various exceptions like non-availability of OOP or the delay or non-availability of evidence are handled by [[Evidence Portal]] and [[Data Logistics]] . If all is well , the Evidence response is composed and prepared for transfer ([[Evidence Portal]]), encrypted and digitally signed using [[Trust Architecture]] and ultimately exchanged using [[Data Logistics]].
		+
		+	<span style="background:#FFFF00">TODO as per target architecture (D2.7) it should be eProcedure Back-office communicating with Evidence Interchange Management</span>

	=== Application Collaborations ===		=== Application Collaborations ===

@@ Line 198: / Line 198: @@
 The figure below shows how application services serve the Data Consumer process. The application services are realized by application collaborations.
 [[File:Lookup Process Realization - DC.png|alt=|none|thumb|Process realization of the Data Consumer]]
-The process starts by an external business trigger identifying the need for an evidence or update thereof. With he help of the [[Information Desk]] the required cross-border evidence is determined and the relevant routing information is looked up.
+The process starts by an external business trigger identifying the need for an evidence or update thereof. With the help of the [[Information Desk]] the required cross-border evidence is determined and the relevant routing information is looked up.
 Next the Evidence can be requested, the request message is encrypted and digitally signed using the [[Trust Architecture]]. The evidence is exchanged using [[Data Logistics]] and can be tracked using [[Evidence Interchange Management]]. The signature of the Evidence response message is validated and the message decrypted ([[Trust Architecture]]). Next the evidence can be evaluated by the DC ([[EProcedure Portal]]) and if all is well the public service can be (or continued to be) provided.

@@ Line 202: / Line 202: @@
 Next the Evidence can be requested, the request message is encrypted and digitally signed using the [[Trust Architecture]]. The evidence is exchanged using [[Data Logistics]] and can be tracked using [[Evidence Interchange Management]]. The signature of the Evidence response message is validated and the message decrypted ([[Trust Architecture]]). Next the evidence can be evaluated by the DC ([[EProcedure Portal]]) and if all is well the public service can be (or continued to be) provided.
-TODO After discussion with DBA change Req/Evidence matching (eProcedure Portal) to "Assess Evidence" in eProcedure Back-office.
+<span style="background:#FFFF00">TODO After discussion with DBA change Req/Evidence matching (eProcedure Portal) to "Assess Evidence" in eProcedure Back-office.</span>
 The figure below shows how application services serve the Data Provider process. The application services are realized by application collaborations.[[File:Lookup Process Realization - DP.png|alt=|none|thumb|Process Realization of the Data Provider]]

← Older revision		Revision as of 14:51, 24 August 2021
Line 201:		Line 201:

	Next the Evidence can be requested, the request message is encrypted and digitally signed using the [[Trust Architecture]]. The evidence is exchanged using [[Data Logistics]] and can be tracked using [[Evidence Interchange Management]]. The signature of the Evidence response message is validated and the message decrypted ([[Trust Architecture]]). Next the evidence can be evaluated by the DC ([[EProcedure Portal]]) and if all is well the public service can be (or continued to be) provided.		Next the Evidence can be requested, the request message is encrypted and digitally signed using the [[Trust Architecture]]. The evidence is exchanged using [[Data Logistics]] and can be tracked using [[Evidence Interchange Management]]. The signature of the Evidence response message is validated and the message decrypted ([[Trust Architecture]]). Next the evidence can be evaluated by the DC ([[EProcedure Portal]]) and if all is well the public service can be (or continued to be) provided.
		+
		+	TODO After discussion with DBA change Req/Evidence matching (eProcedure Portal) to "Assess Evidence" in eProcedure Back-office.

	The figure below shows how application services serve the Data Provider process. The application services are realized by application collaborations.[[File:Lookup Process Realization - DP.png\|alt=\|none\|thumb\|Process Realization of the Data Provider]]		The figure below shows how application services serve the Data Provider process. The application services are realized by application collaborations.[[File:Lookup Process Realization - DP.png\|alt=\|none\|thumb\|Process Realization of the Data Provider]]

@@ Line 176: / Line 176: @@
 |DO
 |Service
-|The DO prepares the extracted evidence to be send as an evidence response. Depending on the level of harmonization of the evidence type this task can differ in complexity. If a canonical evidence definition is agreed, as is the case in [[Doing Business Abroad Pilot|DBA]], then this task includes the translation of the national definitions into the canonical evidence.
+|The DO prepares the extracted evidence to be sent as an evidence response. Depending on the level of harmonization of the evidence type this task can differ in complexity. If a canonical evidence definition is agreed, as is the case in [[Doing Business Abroad Pilot|DBA]], then this task includes the translation of the national definitions into the canonical evidence.
 |-
 |Transfer evidence

@@ Line 111: / Line 111: @@
 == Business Process of the Evidence Lookup ==
 The Figure below shows the BPMN Business Process Collaboration view of the Evidence Subscription Process, which is either triggered because a [[Subscription and Notification Pattern|Notification]] was interpreted to require an evidence update, or it is triggered by a Public Service procedure that requires an evidence that can be fetched based in bilateral agreement or national or Union law. Please note that this pattern is '''not''' triggered by the user. The Evidence Lookup could therefor also be used in a traditional procedure based on a physical transaction with the user.[[File:Evidence Lookup pattern.png|alt=Evidence Lookup Business Process Collaboration|none|thumb|Evidence Lookup Business Process Collaboration]]As you can see in the Business Process Collaboration view above, the process of looking up an evidence for the first time or looking up a new version of the evidence is essentially identical. These variants have, however, different legal implications and might consequently differ in the authorization aspect of the Evaluate Evidence Request activity. The process is also very similar to the [[Intermediation Pattern]], even through not all activities listed below are equally relevant for all use cases. The Establish Subject Identity activity, for example, is not relevant for all business use-cases that can base identification on an European unique identifier. The DC looks up the correct DP, which might simplified for pilot purposes, and sends an Evidence request to the DP. The DP checks the request, extracts the evidence and returns the Evidence response that is then saved by the DC.
 {| class="wikitable sortable"
 |+Business activities of the Lookup pattern

@@ Line 116: / Line 116: @@
 === Activity Table ===
 {| class="wikitable sortable"
 |'''Activity /   UC'''
 |'''Role'''
@@ Line 199: / Line 200: @@
 The figure below shows how application services serve the Data Consumer process. The application services are realized by application collaborations.
-[[File:Lookup Process Realization - DC.png|alt=|none|thumb]]
+[[File:Lookup Process Realization - DC.png|alt=|none|thumb|Process realization of the Data Consumer]]
 The process starts by an external business trigger identifying the neeed for an evidence or update thereof. With he help of the [[Information Desk]] the required cross-border evidence is determined and the relevant routing information is looked up.
 Next the Evidence can be requested, the request message is encrypted and digitally signed using the [[Trust Architecture]]. The evidence is exchanged using [[Data Logistics]] and can be tracked using [[Evidence Interchange Management]]. The signature of the Evidence response message is validated and the message decrypted ([[Trust Architecture]]). Next the evidence can be evaluated by the DC ([[EProcedure Portal]]) and if all is well the public service can be (or continued to be) provided.
-The figure below shows how application services serve the Data Provider process. The application services are realized by application collaborations.[[File:Lookup Process Realization - DP.png|alt=|none|thumb]]
+The figure below shows how application services serve the Data Provider process. The application services are realized by application collaborations.[[File:Lookup Process Realization - DP.png|alt=|none|thumb|Process Realization of the Data Provider]]
 The Evidence request is received via [[Data Logistics]] and with the help of [[Trust Architecture]] the DP checks the signature of the request and decrypts it. An Authority check may be performed using the [[Information Desk]] establishing that the DC is allowed to request the evidence type, which is mort likely not in scope of teh pilot with a limited number of participants. Next the subject identity is established using [[Trust Architecture]]. If successful, the evidence is extracted by [[Evidence Retrieval]] Retrieval and transformed to cannonical form ([[Evidence Portal]]). Various exceptions like non-availability of OOP or the delay or non-availability of evidence are handled by [[Evidence Portal]] and [[Data Logistics]] . If all is well , the Evidence response is composed and prepared for transfer ([[Evidence Portal]]), encrypted and digitally signed using [[Trust Architecture]] and ultimately exchanged using [[Data Logistics]].

← Older revision		Revision as of 19:42, 29 June 2021
Line 1:		Line 1:
−	The pattern is used by the Doing Business Abroad Pilot in [[Use Case "Doing Business in Another Member State" (DBA UC2)]].	+	The Lookup pattern is used by the Doing Business Abroad Pilot in [[Use Case "Doing Business in Another Member State" (DBA UC2)]].

	== Functional Variants of the Lookup Pattern ==		== Functional Variants of the Lookup Pattern ==

← Older revision		Revision as of 19:42, 29 June 2021
Line 312:		Line 312:

	As can be concluded from the above analysis the API approach is definitely more complex than the initially envisage lookup pattern from D2.1 (a simple synchronous request/reply to obtain a few attributes). However it holds promise in the sense that we could leverage existing APIs in the MSs to facilitate cross-border data exchange instead of costly redevelopments to make it fit e the Delivery/AS4 solution.		As can be concluded from the above analysis the API approach is definitely more complex than the initially envisage lookup pattern from D2.1 (a simple synchronous request/reply to obtain a few attributes). However it holds promise in the sense that we could leverage existing APIs in the MSs to facilitate cross-border data exchange instead of costly redevelopments to make it fit e the Delivery/AS4 solution.
−
−	~~== Used by the following use cases ==~~
−
−	~~[[Use Case "Doing Business in Another Member State" (DBA UC2)\|DBA (UC2)]]~~