Integrate enmeshed

If the value of a RepositoryAttribute changes, this can be replicated in enmeshed with this use case. It allows you to update the content and keeps a coherent history of all versions by establishing a doubly linked list, using the LocalAttribute’s parameters succeeds and succeededBy. Hence, every LocalAttribute may have exactly one predecessor and one successor. In case you shared the preceeding version of the RepositoryAttribute, the corresponding own shared IdentityAttribute copy will only be succeeded, if you decide to notify the peer of the respective shared IdentityAttribute about the succession.

Parameters

  • predecessorId: the id of the RepositoryAttribute you want to succeed
  • The successorContent according to the parameters of an IdentityAttribute as described in the data model, except for the owner, which is automatically set to your Address

On Success

  • The response returns a predecessor and a successor LocalAttribute.
  • The predecessor is an updated version of the RepositoryAttribute belonging to predecessorId, having the succeededBy field set to the successor’s id.
  • The successor is a new RepositoryAttribute with the updated successorContent. Its succeeds property links to the predecessor.

On Failure

  • The response cannot be created, if the predecessorId belongs to a RelationshipAttribute.
  • The response cannot be created, if the predecessorId belongs to an IdentityAttribute with a shareInfo.
  • The response cannot be created, if the LocalAttribute already has a successor.
  • The response cannot be created, if the successorContent contains invalid changes, e.g. of the value type.
  • The response cannot be created, if the parameters are malformed.

How to execute this use case with the Connector?

The Connector is our first-class citizen, thus we provide you with a detailed API description for every use case. This use case can be executed with the REST API of the Connector which you can Access the Connector.
Corresponding interactive API docs excerpt: