Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Introductions to Adaptors can be found on the Introduction to YOUnite page and the Adaptors page.

...

The YOUnite API Documentation can be found at https://younite.us/api

...

Adaptor Workflow

The workflow required in getting a fully functioning adaptor are as followsFollow this workflow to get an adaptor fully operational:

  1. Add an Adaptor Type using the YOUnite UI's Adaptor Types page (or YOUnite API endpoint /adaptorTypes). Adaptor types are not required since all adaptor will default to the "default" adaptor type. Adaptor types are designed to make configuring an adaptor easier especially for deployments that will be deploying many adaptors of the same type.
  2. Follow the adaptor's README on where to load the adaptor software on the instance (e.g. docker image, VM, cloud instance, local system). It must be on an instance that can connect to the YOUnite message bus.
  3. In the YOUnite UI Adaptor's page (or YOUnite API endpoint /zones/<target-zone-uuid>/adaptors ) add the adaptor to the target zone specifying the adaptor's type (or just specify the "default" type).
  4. The prior step will generates then necessary configuration (Adaptor UUID, clientId and clientSecret for connecting to the YOUnite message bus),  the Adaptor will need these at startup. Typically, these can be added to the adaptor's adaptor.yml file, the adaptor's property file or set in the adaptor's environment variables if using a staging tools such as Kubernetes.
  5. Set the adaptor capabilities and/or configuration (metadata) in the YOUnite UI's adaptor page or the API (PUT /zones/<target-zone-uuid>/adaptors/<adaptor-uuid>). See the adaptor README for capability and metadata settings.
  6. Deploy the adaptor. Once it is running you can:
    1. Change an adaptor's state.
      1. Pause
      2. Play
    2. Manage the adaptor.
      1. Delete an Adaptor
      2. Get new Credentials for an adaptor 

...

Once the adaptor has been added (posted) and configured, it can be launched. It should successfully connect to the hub and move briefly into the "Configured" state and then into the "Play" state unless otherwise configured.

TODO KEVIN: Debugging

...

Once an adaptor is added (step 1, above) it is in the "Posted" state. The states normally set by the YOUnite Data Hub are: POSTED, CONFIGURED, and DOWN.

The adaptor moves between states as follows:

Adaptor States

...

The adaptor has:

  • Connected successfully to the YOUnite Datahub via the message bus/broker
  • Subscribed to the appropriate message broker topics
  • Created its message broker queue

...

Play Read-Only

...

Code Block
languagejs
PUT /zones/zone-uuid/adaptors/adaptor-uuid/ops

Before making a request, the adaptor's changeVersion needs to be retrieved by peforming a GET on the adaptor:

Code Block
languagejs
GET /zones/3c9000a9-3eb6-41fe-a11b-5a5859020c65/adaptors/3dfcc03d-e5d4-4d57-9e9b-5c5d2db32f9a

A response that includes the adaptor's changeVersion is returned:

Code Block
languagejs
{
    "uuid": "3dfcc03d-e5d4-4d57-9e9b-5c5d2db32f9a",
    "name": "Test Adaptor1",
    "zoneUuid": "661f5d76-6bc7-4fc0-97fd-f331ab683379",
    "state": "ADAPTOR_POSTED",
    "dateCreated": 1503634367407,
    "lastUpdated": 1503635641288,
    "changeVersion": 4117664412
}

...

The following request and request body will change an adaptor's state to "pause": 

Code Block
languagejs
PUT /zones/661f5d76-6bc7-4fc0-97fd-f331ab683379/adaptors/3dfcc03d-e5d4-4d57-9e9b-5c5d2db32f9a
Code Block
languagejs
{
	"state": "ADAPTOR_PAUSE",
	"changeVersion": 4117664412
}

...

The following request and request body will change an adaptor's state to "play": 

Code Block
languagejs
PUT /zones/661f5d76-6bc7-4fc0-97fd-f331ab683379/adaptors/3dfcc03d-e5d4-4d57-9e9b-5c5d2db32f9a
Code Block
languagejs
{
	"state": "ADAPTOR_PLAY",
	"changeVersion": 4117664412
}

...

The following request and request body will change an adaptor's state to "play read only": 

Code Block
languagejs
PUT /zones/661f5d76-6bc7-4fc0-97fd-f331ab683379/adaptors/3dfcc03d-e5d4-4d57-9e9b-5c5d2db32f9a
Code Block
languagejs
{
	"state": "ADAPTOR_PLAY_RO",
	"changeVersion": 4117664412
}

Changing an Adaptor's Operational State

The Once an adaptor is in the PLAY state, messages can be passed an adaptor to the datahub, and vice versa. Two situations may occur that cause the adaptor to no longer send/receive messages. The first is if the API is used to change the state to PAUSE. The second is in the rare case something goes awry between the datahub and adaptor. This could be the message bus service itself is down/restarting, the queue used for communication has an issue, or possibly something else. In the latter cases, usually the adaptor will auto restart and that will start the Datahub startup sequence again and communications should be re-established. If that does not occur, it may be required to dig further in to the YOUnite logs and possibly the adaptor logs to determine what might have happened.

6a. Change an Adaptor's State
Anchor
adaptorState
adaptorState

Once an adaptor is added (step 1, above) it is in the "Posted" state. The states normally set by the YOUnite Data Hub are: POSTED, CONFIGURED, and DOWN. The ../controls endpoint changes an adaptor's state to operational states and those normally set only by the datahub. However, there may be situations where you want to use this endpoint to set these states, such as if an adaptor is an unknown state and restarting the adaptor does not provide a remedy.

Note: Under normal circumstances this resource should never be used and it can render an adaptor and the source entity read/write requests in an unknown state.

This resource overwrites the adaptor to a state normally set by the YOUnite Data Hub. Valid states for this request are the normal adaptor operational states:

  • ADAPTOR_PAUSE
  • ADAPTOR_PLAY
  • ADAPTOR_PLAY_RO

And the states normally set only by the datahub:

  • ADAPTOR_POSTED
  • ADAPTOR_CONFIGURED
  • ADAPTOR_DOWN

...

languagejs

...

, and DOWN.

The adaptor moves between states as follows:

Adaptor States

StateDescription
PostedAdaptor is successfully POSTed. An API consumer can make this request or it can be done through the YOUnite UI.
Configured

The adaptor has:

  • Connected successfully to the YOUnite Datahub via the message bus/broker
  • Subscribed to the appropriate message broker topics
  • Created its message broker queue
PauseThe adaptor is running but not accepting adaptor (read/write) requests.
PlayThe adaptor is accepting read and write requests.


An adaptor state can be changed using the request including JSON request body:

Anchor
opsAdaptorState
opsAdaptorState

Code Block
languagejs
PATCH /zones/zone-uuid/adaptors/adaptor-uuid

Request body to pause:
{
    "state": "ADAPTOR_PAUSE"
}

Request body to resume:
{
    "state": "ADAPTOR_PLAY"
}


6b. Manage an Adaptor

See the YOUnite API documentation (https://younite.us/api) for more requests that can be made to the adaptors endpoint.

...

Code Block
languagejs
DELETE /zones/661f5d76-6bc7-4fc0-97fd-f331ab683379/adaptors/3dfcc03d-e5d4-4d57-9e9b-5c5d2db32f9a

Note: When you delete an adaptor it is a soft delete (meaning the adaptor's "active" setting will be set to false). A soft-delete for entities avoids purging important information, including that which can be used to associate past activity in the system, such as logged events, zone, and adaptor type.

However, the linking (mapping) between the (YOUnite) Data Record and the source entities in the source system attached to the deleted adaptor will be hard deletes. Linking for deleted adaptors is hard-deleted as this particular data carries no useful additional data or metadata (the link entities are just an adaptorUuid and a drUuid).  Post-delete, an adaptor's linking history can still be viewed in system logs that should include all the relevant details about that link, as well as a log timestamp.


Get Credentials for an Adaptor

...