View Source

3.1 Introduction

A Common Service MAY provide a Lifecycle Management (LCM) Interface for a bulk update of the information stored in the Common Services of a Member State. This section provides the technical specification of this interface as it will be implemented by the European Commission to implement its Common Services. This LCM interface is a highly constrained profile based on the RegRep 4.0 LCM Manager Interface Specification that has the following limitations:

Only the SubmitObjects protocol is supported.
Each Member State shall authorize at most one authorized competent authority to make submissions.
A submission is linked to a single Member State and made on behalf of that Member State.
Submission linked to a single Member State do not affect data related to other Member States.
A submission contains a complete, internally consistent set of data. It is not possible to incrementally submit objects using a series of submissions.
In case of a successful submission made for a Member State to a Common Service, any existing data previously submitted to the Common Service for that Member State is replaced. This obviates the need for the RemoveObjects protocol.
In case of an unsuccessful submission made for a Member State to a Common Service, the existing data held by the Common Service is retained.

Since object submission updates data, this profile use eDelivery for secure and reliable messaging as described below.

A service implementing the LCM specification MUST define a Classification Scheme using a unique urn. The Classification Scheme MUST contain all the Classification Nodes that properly characterize the registry objects and associations under submission.

The SubmitObjects Protocol defines a SubmitObjectsRequest message for sending the objects to be added together with successful and error responses. The following subsections define these messages in detail.

3.2 The Regrep LCM Submission

For the LCM submission, the profile uses the SubmitObjectsRequest message, as defined by the RegRep 4.0 LCM Manager Interface Specification SubmitObjects Protocol. A detailed guideline how the SubmitObjects Protocol is implemented for the Common Services is illustrated in the following sections:

LCM Interface Specification of the Evidence Broker (section 3.2.5)
LCM Interface Specification of the Data Service Directory (section 3.1.5 and 3.1.6)

The message MUST contain a unique id and one Registry Object List containing the Registry Objects under submission.

The attribute “checkReferences” on SubmitObjectsRequest MUST be set to “true” to express that a server MUST check submitted objects and make sure that all references via reference attributes and slots to other RegistryObjects are resolvable. If a reference does not resolve then the server MUST return rs:InvalidRequestExceptionType (LCM:ERR:0003).

An optional rim:Slot "SpecificationIdentifier" to indicate the version of the LCM specifications. Note:

For the DSD LCM Refactored the use of the rim:Slot "SpecificationIdentifier" is mandatory with value "oots-lcm:v1.0"
For the DSD LCM Baseline the use of the rim:Slot "SpecificationIdentifier" is not allowed.
For the EB LCM the use of the rim:Slot "SpecificationIdentifier" is only mandatory in cases where a SubmitObjectsRequest is combined with DSD LCM Refactored.

Each contained Registry Object MUST contain:

A Classification with a Classification Node that is part of the Classification Scheme as defined by the service implementing the profile.
An id attribute that must be unique using a UUID version 4 urn. This logical id MUST be used in the contained associations, for associating source and target registry objects.
A Slot with a name that is identical with the Classification's Classification Node. The slot MUST contain the information of the Registry Object according to the service profiled specification

Each contained Registry Object that is an Association MUST Contain:

the xsi:type which MUST be of value rim:AssociationType
An id attribute that must be unique using a UUID version 4.
the sourceObject attribute that denotes the starting point of the association. The attribute value MUST be the UUID v4 urn id of a Registry Object
the targetObject attribute that denotes the ending point of the association. The attribute value MUST be the UUID v4 urn id of a Registry Object
The type attribute which MUST use Classification Nodes, defined as extensions to the canonical AssociationType Classification Scheme of RegRep v4.0

The following diagram illustrates the principle structure of the LCM SubmitObjectRequest.

The example below illustrates a sample structure:

<lcm:SubmitObjectsRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:4.0"
  xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:4.0"
  xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:4.0"
  xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:4.0"
  xmlns:sdg="http://data.europa.eu/sdg#"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  id="urn:uuid:4dd63731-1b16-484e-af7c-baaf492f9073"
  checkReferences="true">

  <rim:RegistryObjectList>
    <rim:RegistryObject id="urn:uuid:a1be6e74-e9ba-4d44-b04c-0376f367b8fd">
      <rim:Classification id="urn:uuid:e8cd682c-08f2-4f90-a310-dc2c4d785fdb" 
           classificationScheme="urn:fdc:oots:classification:example" 
           classificationNode="ExampleNode"/>

      <rim:Slot name="ExampleNode">
        <rim:SlotValue xsi:type="rim:AnyValueType">
         <!-- Registry Object Data -->
        </rim:SlotValue>
      </rim:Slot>
    </rim:RegistryObject>

    <rim:RegistryObject id="urn:uuid:9d72ced7-638e-4023-9712-d7e871bf7d3d">
       <rim:Classification id="urn:uuid:e8cd682c-08f2-4f90-a310-dc2c4d785fdb" 
           classificationScheme="urn:fdc:oots:classification:example" 
           classificationNode="ExampleNode"/>
 
     <rim:Slot name="ExampleNode">
         <rim:SlotValue xsi:type="rim:AnyValueType">
         <!-- Registry Object Data -->
        </rim:SlotValue>
      </rim:Slot>

    </rim:RegistryObject>

    <!-- Association -->
    <rim:RegistryObject xsi:type="rim:AssociationType" 
         id="urn:uuid:ac720bc9-b967-4858-b3f7-83d26020dab7" 
         sourceObject="urn:uuid:a1be6e74-e9ba-4d44-b04c-0376f367b8fd" 
         targetObject="urn:uuid:9d72ced7-638e-4023-9712-d7e871bf7d3d" 
         type="urn:oasis:names:tc:ebxml-regrep:AssociationType:Serves"/>
  </rim:RegistryObjectList>
</lcm:SubmitObjectsRequest>

3.3 The Regrep LCM Successful Response

Upon a successful SubmitObjectsRequest message submission, the service MUST return a RegistryResponse message that MUST contain:

A requestId attribute with the value of the id of the submitObjectsRequest that this message responds to.
A status attribute with the value "Success"

3.3.1 Implementation Guide of a Regrep LCM Successful Response

The table below defines the elements of the data model illustrated above according to the RegRep 4.0 LCM Manager Interface Specification rs:RegistryResponse.

	Name	Definition	Cardinality	ebRIM type	Data Type	Rules	Domain
	rs:RegistryResponse	Registry Response root element		RegistryResponseType		R-LCM-SUC-001, R-LCM-SUC-002, R-LCM-SUC-007, R-LCM-SUC-008	ebRIM
+	status	Element used to define the status of the RegistryRequest.	1..1	Attribute	Identifier	R-LCM-SUC-005, R-LCM-SUC-006	ebRIM
+	requestId	The unique identifier of the SubmitObjectsRequest to which the RegistryResponse replys.	1..1	Attribute	Identifier	R-LCM-SUC-003, R-LCM-SUC-004	ebRIM

3.3.2 Example of a Regrep LCM Successful Response

The following example shows a successful response to the SubmitObjectsRequest of section 3.1

<RegistryResponse xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rs:4.0"
                  status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
                  requestId="urn:uuid:4dd63731-1b16-484e-af7c-baaf492f9073"/>

3.3.3. Business Rules associated to the Regrep LCM Successful Response

In order to facilitate interoperability of the Regrep LCM Successful Response, a set of business rules is defined to guarantee the correct structure, use and format of information objects. The rule IDs LCM- SUC reference to the EB transaction "LCM Successfull Response". The business rules are listed in section 3.7.

3.4 The Regrep LCM Error Response

When an error occurs during the execution of the SubmitObjectsRequest, the Common Service returns an exception. The exception has the following properties that are profiled for each expected error of the submission request.

xsi:type: The type of the error, selectable from a predefined set of error classes of the LCM Interface of the Common Service.
severity: The severity of the error, selectable from a predefined set of error classes of the LCM Interface of the Common Service.
message: A string describing the error in Human Readable form.
code: A code for the error, specified by the Common Service Technical Design documents.
detail: The detail may contain further freely defined information about the error

3.4.1 Implementation Guide of a Regrep LCM Error Response

The table below defines the elements of the data model illustrated above according to the RegRep 4.0 LCM Manager Interface Specification rs:RegistryResponse.

	Name	Definition	Cardinality	ebRIM type	Data Type	Rules	Domain
	rs:RegistryResponse	Registry Response root element		RegistryResponseType		R-LCM-ERR-001, R-LCM-ERR-002, R-LCM-ERR-017	ebRIM
+	status	Element used to define the status of the RegistryRequest.	1..1	Attribute	Identifier	R-LCM-ERR-005, R-LCM-ERR-006, R-LCM-ERR-007	ebRIM
+	requestId	The unique identifier of the SubmitObjectsRequest to which the RegistryResponse replys.	0..1	Attribute	Identifier	R-LCM-ERR-003, R-LCM-ERR-004	ebRIM
++	rs:Exception	The rs:exeption describes an error which occurs during the processing of a Query Request.	1..n	RegistryExceptionType		R-LCM-ERR-008	ebRIM
++	rs:Exception	The rs:exeption describes an error which occurs during the processing of a Query Request.	1..n	RegistryExceptionType		R-LCM-ERR-008	ebRIM
+++	xsi:type	Describes the nature of the error that occurred.	1..1	Attribute	string	R-LCM-ERR-009, R-LBM-ERR-010	ebRIM
+++	severity	The severity attribute value provides a severity level for the exception. The default value is "urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"	1..1	Attribute	objectReferenceType	R-LCM-ERR-011, R-LBM-ERR-012	ebRIM
+++	message	Is used to add an error message that can be shown and understood by the user of the system.	1..1	Attribute	string	R-LCM-ERR-013	ebRIM
+++	code	A code that corresponds to the status of the system with regard to the processing of a request. If the specific error codes do not cover the reason for failure use the generic error code "other".	1..1	Attribute	string	R-LCM-ERR-015, R-LCM-ERR-016	ebRIM
+++	detail	Is used to describe technical details of the error that might be needed to identify and debug the error.	0..1	Attribute	string		ebRIM

3.4.2 Example of a Regrep LCM Error Response

An Example of an empty result set is provided below.

<?xml version="1.0" encoding="UTF-8"?>
<rs:RegistryResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                     xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:4.0"
                     xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:4.0"
                     xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:4.0"
                     status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure"
                     requestId="urn:uuid:4dd63731-1b16-484e-af7c-baaf492f9073">

   <!-- Valid parameter combinations are defined by the LCMErrorResponseCodes -->
  <!-- The Codelists LCMErrorCodes provides the values for xsi:type, message and code  -->
  <!-- The ErrorSeverity provides allowed values for severity. The default value for LCM is "Error". -->
  <!-- The value of code attribute of a rs:Exception  MUST be a code  matching the type  provided by code list 'LCMErrorCodes' -->
  <!-- The detail may contain further freely defined information about the error -->

  <rs:Exception
      xsi:type="rs:InvalidRequestExceptionType"
      severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"
      message="A registry object in the Request does not comply with the specification"
      detail="DataServiceEvidenceType 3510efdc-172a-4b14-a625-c3d0e49f0a39"
      code="LCM:ERR:0001">
  </rs:Exception>
</rs:RegistryResponse>

3.4.3 Common Error Codes of a Regrep LCM Error Response

The following table provides the list of LCMErrorResponseCodes for the expections. The "detail" attribute is a placeholder that may contain further information for specific errors.

#	Title (not used by the exception)	Type	Code	Message
1	Invalid registry object	rs:InvalidRequestExceptionType	LCM:ERR:0001	A registry object in the Request does not comply with the specification
2	Invalid association	rs:InvalidRequestExceptionType	LCM:ERR:0002	An association in the Request does not comply with the specification
3	Inconsistent dataset	rs:InvalidRequestExceptionType	LCM:ERR:0003	The dataset provided failed to pass the validation and integrity check

3.4.4. Business Rules associated to the LCM Error Response

In order to facilitate interoperability of the Regrep LCM Error Response, a set of business rules is defined to guarantee the correct structure, use and format of information objects. The rule IDs LCM-ERR reference to the transaction "LCM Error Response" . The business rules are listed in section 3.7.

3.5 Combined Regrep LCM Submission of DSD and EB artifacts

A combined RegRep LCM Submission of DSD and EB artifacts is another allowed SubmitObjectsRequest message and method how to update the CS. The Combined RegRep LCM Submission follows similar rules as described in the section 3.2 (Regrep LCM Submission). It therefore, however, combines the specification and rules described in:

LCM Interface Specification of the Evidence Broker (section 3.2.5)
LCM Interface Specification of the Data Service Directory (only 3.1.6)

The combined RegRep LCM Submission of DSD and EB artifacts can be only used for the refactored DSD LCM.

The definition rim:RegistryObjectList containing the rim:RegistryObject and the use of rim:Classification with a ClassificationNode definitions as well as the rim:AssociationType with the defined type of association with sourceObject and targetObject MUST adhere to these specifications exactly.

The rim:Slot "SpecificationIdentifier" is mandatory in cases where a SubmitObjectsRequest is combined with artifacts for EB and DSD.

An XML example for a combined LCM Submission of DSD and EB artifacts is provided in the following Git folder.

A difference exists in validating combined Regrep LCM Submission message. Since the structure of these message changes, a new set of business rules was defined to prove the structure of XML instances. For validating combined RegRep LCM Submission of DSD and EB artifacts the following schematron files that are illustrated in the figure need to be applied to XML instances that can be found in the following Git folder:

DSD-SUB_RF-C.sch
EB-SUB-C.sch
LCM-SUB-S.sch

OOTS Technical Design Documents > 3.6.3 The Lifecycle Management Specification (June 2024) > Documents.png

While DSD-SUB_RF-C.sch and EB-SUB-C.sch are exactly the same business rules as the individual submission of DSD and EB artefacts, the rule set for checking the structure, LCM-SUB-S.sch, combines many rules from (DSD-SUB_RF-S and EB-SUB-S.sch) into a single schematron file and thereby partially modifies them to ensure that a correct structure can be proven. The business rules can be also found in section 3.7. Business Rules of the Regrep LCM of this document.

3.6 eDelivery Configuration

Since object submission updates data, the LCM interface uses eDelivery for secure and reliable messaging. Use of eDelivery MUST follow the OASIS ebXML Messaging Protocol Binding for RegRep Version 1.0. That specification provides details needed for proper eDelivery configuration, including the values for the AS4 Service and Action message headers:

The Service header is set as follows:
- The header value is set to LifecycleManager.
- The type attribute is set to urn:oasis:names:tc:ebcore:ebrs:ebms:binding:1.0.
The Action header is set to:
- SubmitObjectsRequest for the request.
- SubmitObjectsResponse for the successful response.
- ExceptionResponse for the error response.

The four parties are conventionally referred to using Cn labels, where C stands for "corner", and the n is one of the digits 1 to 4. When submitting LCM object to the common services, the roles are defined as follows:

C1 is the eb:Property name='originalSender' party which is the Member State that submits an LCM SubmitObjectsRequest to the Common Services. It becomes C4 and eb:Property name='finalRecipient' the in the LCM SubmitObjectsResponse or ExceptionsRepsonse.
C2 is an Access Point that sends LCM SubmitObjectsRequest to the Common Services on behalf of C1 expressed through the eb:From element. It becomes C3 and eb:To the in the LCM SubmitObjectsResponse.
C3 is the Access Point of the Common Services that receives the LCM SubmitObjectsRequest from the Member state expressed through the eb:To element. It becomes C2 and eb:From the in the LCM SubmitObjectsResponse.
C4 is the eb:Property name='finalRecipient' party which is the Common Services that receive an LCM SubmitObjectsRequest from the MS. It becomes C4 and eb:Property name='originalSender' the in the LCM SubmitObjectsResponse or ExceptionsRepsonse.

At most one competent authority per Member State will be allowed to send object submission requests to the Common Service. The party identifier for this authority will be used as originalSender in LCM requests and as finalRecipient in LCM responses. The Common Services are currently the only recipient of the message that is labelled as finalRecipient of the LCM SubmitObjectsResponse. Successfull request are responded with the LCM SubmitObjectsResponse by the CS. The Common Service MUST reject requests from parties other than authorized parties using ExceptionsRepsonse of type AuthorizationException.

In the LCM SubmitObjectsRequest, the roles are defined in the following way:

The eb:From element is set as follows:
- eb:PartyId/@type MUST either use the prefix 'urn:cef.eu:names:identifier:EAS:[Code]' and a code being part of the code list 'EAS' (Electronic Address Scheme ) OR it MUST use the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code]' and a code being part of the code list ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’.
- The value of eb:PartyId is the identifier of the AS4 gateway that is sending the message on behalf of C1. It MUST be a valid identifier according to a scheme described by 'EAS' (Electronic Address Scheme ) or it MUST be MS defined in case of unregistered scheme.
The eb:To element is set as follows:
- eb:PartyId/@type is set to the fixed value 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:oots'.
- The value of eb:PartyId is the identifier 'CS-LCM-AP' for the Common Services LCM Access Point.
The eb:Property name='originalSender'
- eb:Property/@type MUST either use the prefix 'urn:cef.eu:names:identifier:EAS:[Code]' and a code being part of the code list 'EAS' (Electronic Address Scheme ) OR it MUST use the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code]' and a code being part of the code list ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’.
- The value of eb:Property is the identifier of the competent Member State authority that is sending the LCM SubmitObjectsRequest. It MUST be a valid identifier according to scheme described by 'EAS' (Electronic Address Scheme ) or it MUST be MS defined in case of unregistered schemes.
The eb:Property name='finalRecipient'
- eb:Property/@type is set to the fixed value 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:oots'.
- The value of eb:PartyId is the identifier 'CS-LCM-AP' for the Common Services.

In the LCM SubmitObjectsResponse, the roles are defined in the following way:

The eb:From element is set as follows:
- eb:PartyId/@type is set to the fixed value 'urn:oasis:names:tc:ebcore:partyid-type:unregistered'.
- The value of eb:PartyId is the identifier 'CS-LCM-AP' for the Common Services LCM Access Point.
The eb:To element is set as follows:
- eb:PartyId/@type MUST either use the prefix 'urn:cef.eu:names:identifier:EAS:[Code]' and a code being part of the code list 'EAS' (Electronic Address Scheme ) OR it MUST use the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code]' and a code being part of the code list ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’
- The value of eb:PartyId is the identifier of the AS4 gateway that is receiving the message on behalf of C1. It MUST be a valid identifier according to a a scheme described by 'EAS' (Electronic Address Scheme ) or it MUST be MS defined in case of unregistered scheme.
The eb:Property name='originalSender'
- eb:Property/@type is set to the fixed value 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:oots'.
- The value of eb:PartyId is the identifier 'CS-LCM-AP' for the Common Services LCM Access Point.
The eb:Property name='finalRecipient'
- eb:Property/@type MUST either use the prefix 'urn:cef.eu:names:identifier:EAS:[Code]' and a code being part of the code list 'EAS' (Electronic Address Scheme ) OR it MUST use the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code]' and a code being part of the code list ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’
- The value of eb:Property is the identifier of the competent Member State authority that is receiving the message. It MUST be a valid identifier according to a scheme described by 'EAS' (Electronic Address Scheme ) or it MUST be MS defined in case of unregistered schemes.

For general OOTS configuation, use of eDelivery for LCM MUST also follow the OOTS eDelivery configuration as specified in chapter 4.7. This means that the Access Point of the authorized competent authority is pre-configured for message exchange with the Access Point of the Common Service and that the four corner topology profile enhancement is used.

3.7. Business Rules of the Regrep LCM

3.7.1. Introduction

In order to facilitate interoperability of the Regrep LCM, a set of business rules is defined to guarantee the correct structure and content format of information objects in the different transactions. The transactions are distinguished by different IDs:

LCM- SUC: The rule IDs reference to the transaction "LCM Successfull Response" (section 3.3).
LCM- ERR: The rule IDs reference to the transaction "LCM Error Response" (section 3.4).
LCM-SUB: The rule IDs refer to the transaction "Combined Regrep LCM Submission of DSD and EB artifacts" (section 3.5)

The Rule ID is used to identify the rule and to have an error code next to the rule description. Business rules that guarantee the correct structure of the message are using the prefix "S" before the number (e.g. S009) whereas business rules that prove the information content are using the prefix "C" before the numer (e.g. C012). The Element and Location points to the correct information object that is affected by the rule. Each business rule is associated with an error level (role) that expresses a validation result when an XML instance is proven against the rules through schematron validation:

caution: A hint that an additional object is needed in some cases; It may not be wrong, but care is required.
warning: Offering recommendations to improve the quality of the instance or regain full validity; Something wrong has happened, but it does not necessarily require action.
fatal: The rule point to a major issue of consistency or data correctness. Something so bad that processing or validation should or did stop.

Rule descriptions containing "MUST" correspond to an error level that is flagged with role fatal, while "SHOULD" rules correspond to an error level that is flagged with role warning. "MAY" rules point to error level flagged with role caution. For each business rule, a corresponding schematron rule is defined that references the same rule ID. Schematrons are used to prove the correctness of instances. Schematron files can be found at https://code.europa.eu/oots/tdd/tdd_chapters/-/tree/master/OOTS-EDM/sch

table { margin-bottom:24px; width:100%; overflow-wrap: break-word; border-collapse: collapse; border:1px solid #CC003D;}
td { padding:5px; border:1px solid black; vertical-align:top; }
table tr td:first-child { width: 15%;}
table tr td:last-child { width: 85%;}

Contents