Child pages
  • Use of GetFileIDs by Integrity Client
Skip to end of metadata
Go to start of metadata

The Scenario is: GetFileIDs from different pillars to integrity client.

This page is not up-to-date. It should be updated along with the tests of FileIDs from all pillars in SLA, FileIDs results via File Exchange, and error messages and alarms in connection with GetFileIDs.

Note This should comply with the way that the Get File operation works.

Following the Get File pattern means we expect the client to send an identify pillars request to pillars in SLA via general topic and the pillars to respond to the request. The integrity client may however already have the information on the pillars in which case the identify primitive may be skipped, and we go directly to the GetFileIDs primitive:

The scenario has 2 steps:

  • (1) request from client to pillars in SLA
  • (2) response from pillars

The scenario is firstly described via illustrations, followed by concrete values for the general message format (see bitrepository-message-xml xsd's), as well as data from data transmission protocol. Data required in reply in data transmission is also described.

Request from client to pillars in SLA

Illustration of step (1)

Note Illustration not updated. Messages are sent to the direct queues to the pillars, not to a general topic.

Message from 1a

Message is sent on "Queue for specific SLA client" which works an internal memory for parallel instances of the integrity client. This message may not end up as part of the protocol, since the internal memory may be implemented in different ways.

These message has the same format as the true protocol messages in 1b, except from MessageName = GetFileIDsRequested instead of MessageName = GetFileIDs.

Message from 1b

Messages are sent to the known queues or topics used by the pillars (the ReplyTo's of the identifyPillarsForGetFileIDsResponses if used).

Message from 1b in general format

One message per pillar

Field name

Client values to pillar 2

Client values to pillar 3

Client values to pillar 4

MessageName

GetFileIDsRequest

GetFileIDsRequest

GetFileIDsRequest

CorrelationID

abc1

abc2

abc3

PillarID

pillar2

pillar3

pillar4

FileIDs

*

id1,id2,id3

f*9.arc

ReplyTo

QReplyQueueTime

QReplyQueueTime

QReplyQueueTime

FileAddress

http://a/b.data1

http://a/b.data2

http://a/b.data3

Message example in XML

See this example

Response from pillars

Illustration of step (2)

Message from 2a

The message is sent on "Queue for specific SLA client" which works an internal memory for parallel instances of the integrity client as described for 1a above.

Message from 2b

Response messages are sent via queue "QReplyQueueTime", while alarm messages are sent via General Topic. Pillar 1 should not respond, and pillar 4 does not respond or responds with an error in an alarm message because it is down.*

Message from 2b in general format (responses)

Field name

Pillar 1

Pillar 2

Pillar 3

MessageName

GetFileIDsResponse

GetFileIDsResponse

GetFileIDsResponse

CorrelationID

abc1

abc2

abc3

PillarID

pillar2

pillar3

pillar4

TimeMeasure

2

3.600

<undefined>

TimeUnit

sec

sec

<undefined>

Message from 2b in general format (alarm)

Field name

Pillar 4

MessageName

GetFileIDsResponse

ConversationId

abc3

PillarId

pillar4

alarmSubject

communication

ErrorCode

47

Message from 2b in XML

Pillar 2

<message>
  <messageName>GetDataIDsReply</messageName>
  <conversationId>abc1</conversationId>
  <pillarId>pillar2</pillarId>
  <time>
    <measure>2</measure>
    <unit>sec</unit>
  </time>
</message>

Pillar 3

<message>  <messageName>GetDataIDsReply</messageName>
  <conversationId>abc2</conversationId>
  <pillarId>pillar3</pillarId>
  <time>
    <measure>3600</measure>
    <unit>sec</unit>
  </time>
</message>

Pillar 4

<message>
  <messageName>Alarm</messageName>
  <conversationId>abc3</conversationId>
  <pillarId>pillar4</pillarId>
  <error>
    <alarmSubject>communication</alarmSubject>
    <errorCode>47</errorCode>
  </error>
</message>

Note that this alarm message format is not finished yet. Please refer to Get Status.

Data transmission from 2c

Data transmission via

The delivered data must as minimum include the following informaiton per data unit:

  • data Id
  • date for when the file was last seen on pillar (can be long be response)

TODO Complete Messages

  • No labels