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>
  <operationId>GetTime</operationId>
  <conversationId>scen2</conversationId>
  <pillarIds>
    <pillarId>pillar1</pillarId>
    <pillarId>pillar2</pillarId>
    <pillarId>pillar4</pillarId>
  </pillarIds>
  <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>
  <operationId>GetTimeReply</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>
  <operationId>GetTimeReply</operationId>
  <conversationId>scen2</conversationId>
  <pillarId>pillar1</pillarId>
  <dataIds>
    <dataId>Id2</dataId>
  </dataIds>
  <time>
    <measure>2</measure>
    <unit>sek</unit>
  </time>
</message>

Pillar 2

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

Pillar 4

<message>
  <operationId>GetTimeReply</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>
  <operationId>Get</operationId>
  <conversationId>scen2</conversationId>
  <pillarIds>
    <pillarId>pillar2</pillarId>
  </pillarIds>
  <dataIds>
    <dataId>Id1</dataId>
  </dataIds>
  <token>http:/a/b.data</token>
</message>

Msg2

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

Msg3

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

Dataoverførelse fra 2b

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

Spørgsmål og mulige udvidelser

• *Oprettes private køer dynamisk? *
  I praksis kunne det være rart at vide hvor lang tid det tager at oprette/nedlægge en kø. Hvis det lang tid, giver det så mening, at etablere private køer? Hvis alternativet er, at oprette alle (SLA-) relevante kombinationer af klineter/pillars, etc. Det må vi teste. (Bemærkning: Besked fra 2a sendes på "Klient1 To Pillar2". Hvorfor ikke 'bare' "Pillar2"?)
• *Forslag: Udvide den indledende forespørgsel på pillars, så der også returneres hvilke datapakker, der er til rådighed. *
  Dette er nødvendigt for near-offline pillars, hvor der kan være forskellige klargøringstider pr. pakke. (Alternativt: At begrænse antallet af dataIDs til en pr. forespørgsel.
• *Hvis listen af dataID er magen til den oprindeligt udsendte, kan man så undlade, at sende den med tilbage? (Se f.eks pillar2's svar foroven) *
• *Tæller offsett fra 0 eller 1? *
• Er det korrekt, at tokens angives med http og ikke https? Nej!
• *Er det ok, at droppe pillarIds i private køer? *
• Stiller det større krav til en pillar at den selv skal 'dele beskeden op i operationer'? (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)