Udkast til testscenarie 2

Scenariet er: Hent flere datapakker

Dette scenarie er en udvidelse af det første testscenarie. Her skal klienten hente en serie af datapakker. For nemheds skyld bliver der bedt om tre pakker i beskrivelsen forneden.
Man bør også teste med 10 og 100 pakker.
Den generelle kø benyttes indledende men herefter offloades resten af kommunikation til en privat kø, der her antages bare at "være til rådighed". Der benyttes samme conversationID til alle beskeder, sådan at hele forløbet kan følges på tværs af køer.

Setup for dette scenarie bygger i øvrigt på testscenarie 1.
Scenariet går i 4 steps:

• (1a) forespørgsel fra klient til pillars i SLA
• (1b) svar fra pillars
• (2a) specifik get fra klient til specifik pillar
• (2b) svar i form a datatransmission

scenariet er først beskrevet via illustrationer (kommer...) og derefter ved konkrete værdier i generelle beskedformater med efterfølgende XML. Antagelser om de generelle formater er givet til sidst.

Step 1 a+b

Besked fra 1a

Besked sendes på "Topic General to pillars"

Besked fra 1a i det generelle format

Beskeder2 fra 1a i XML

<message>
  <messageName>IdentifyPillarsForGetRequest</operationId>
  <conversationId>scen2</conversationId>
  <dataIds>
    <dataId>Id1</dataId>
    <dataId>Id2</dataId>
    <dataId>Id3</dataId>
  </dataIds>
  <replyQueueName>QReplyQueueTime</replyQueueName>
</message>

Beskeder fra 1b

Beskeder som sendes på kø "QReplyQueueTime"

Beskeder fra 1b i generelle format

• Pillar 3 bør ikke svare, og pillar 4 svarer med error ligesom i testscenarie # Pillar 1 svarer med to svar da det er et near-online system og den ved at Id2 ligger online og Id1 og d3 begge ligger offline. *

Beskeder fra 1b i XML format

Pillar 1

<message>
  <messageName>IdentifyPillarsForGetReply</operationId>
  <conversationId>scen2</conversationId>
  <pillarId>pillar1</pillarId>
  <dataIds>
    <dataId>Id1</dataId>
    <dataId>Id3</dataId>
</dataIds>
  <time>
    <measure>6</measure>
    <unit>min</unit>
  </time>
</message>

Pillar 1

<message>
  <messageName>IdentifyPillarsForGetReply</operationId>
  <conversationId>scen2</conversationId>
  <pillarId>pillar1</pillarId>
  <dataIds>
    <dataId>Id2</dataId>
  </dataIds>
  <time>
    <measure>2</measure>
    <unit>sek</unit>
  </time>
</message>

Pillar 2

<message>
  <messageName>IdentifyPillarsForGetReply</operationId>
  <conversationId>scen2</conversationId>
  <pillarId>pillar2</pillarId>
  <time>
    <measure>2</measure>
    <unit>sec</unit>
  </time>
</message>

Pillar 4

<message>
  <messageName>IdentifyPillarsForGetReply</operationId>
  <conversationId>scen2</conversationId>
  <pillarId>pillar4</pillarId>
  <error>47</error>
</message>

• I dette scenarie svarer Pillar 3 med et forkortet svar, hvor dataIds ikke gentages (se spørgsmål under scenarie 1). Hvis det er muligt at svare uden dataIds, kan det som her fortolkes som at svaret dækker alle datapakker. *

Step 2 a+b

Besked fra 2a

Besked sendes på "Klient1 To Pillar2"

Besked fra 2a i generelle format

Den generelle kø benyttes indledende men herefter offloades resten af kommunikation til en privat kø, der her antages bare at "være til rådighed". Der benyttes samme conversationID til alle beskeder, sådan at hele forløbet kan følges på tværs af køer.

Besked fra 2a i XML format

Msg1

<message>
  <messageName>Get</operationId>
  <conversationId>scen2</conversationId>
  <pillarIds>
    <pillarId>pillar2</pillarId>
  </pillarIds>
  <dataIds>
    <dataId>Id1</dataId>
  </dataIds>
  <token>https:/a/b.data</token>
</message>

Msg2

<message>
  <messageName>Get</operationId>
  <conversationId>scen2</conversationId>
  <pillarIds>
    <pillarId>pillar2</pillarId>
  </pillarIds>
  <dataIds>
    <dataId>Id2</dataId>
  </dataIds>
  <token>https:/b/c.data</token>
</message>

Msg3

<message>
  <messageName>Get</operationId>
  <conversationId>scen2</conversationId>
  <pillarIds>
    <pillarId>pillar2</pillarId>
  </pillarIds>
  <dataIds>
    <dataId>Id3</dataId>
  </dataIds>
  <token>https:/a/b.data</token>
</message>

Dataoverførelse fra 2b

• Dataoverførelse af pakken Id1 via https:/a/b.data fra pillar 2
• Dataoverførelse af pakken Id2 via https:/b/c.data fra pillar 2
• Dataoverførelse af pakken Id3 via https:/c/d.data fra pillar 2