Ook bij poging 2 of hoger, bijbehorend resultaat terugkoppelen op door SIS aangemaakte association-ID

[roelgrif]

Vergelijkbaar probleem met #148. Situatie: poging 1 geleverd door SIS aan TPS met association id X resultaat poging 1 teruggeleverd door TPS aan SIS op association id X Vervolgens: poging 2 geleverd door SIS aan TPS met association id Y resultaat poging 2 teruggeleverd door TPS aan SIS op association id Z met orgAssociationId = X

M.i. niet volgens de OKE dan wel OOAPI standaard. Alleen in het geval het TPS zelf nieuwe pogingen maakt die nog niet door het SIS aangeleverd zijn zouden nieuwe association ID's aangemaakt moeten worden vanuit het TPS; met orgAssociationId = X of Y, dat maakt dan m.i. niet uit (als beide compOffAssId's remaining attempts > 0 hebben kan het TPS kiezen).

[rrutte]

Vanuit TPS zijn er in dit geval twee actieve componentOfferingAssociations op dezelfde componentOffering waardoor niet duidelijk is wat het SIS van het TPS verwacht. Effectief komt het er weer op neer wat een componentOfferingAssociation nu eigenlijk is vanuit OOAPI perspectief en hoe dit geïnterpreteert moet worden. Hybride de verschillende mogelijkheden op basis van een first come first serve basis lijkt met over de SIS'en heen niet transparant.

[roelgrif]

IMHO is het duidelijk dat bij een resultaat op poging 2 niet een resultaat op het association ID van poging 1 (hetzij rechtstreeks, hetzij als origAssociationId) verwacht wordt. Als zo'n resultaat op het associationId van poging 2 terugkomt is een hybride first come first serve m.i. wel mogelijk. Het TPS kan extra pogingen aanmaken die het SIS niet aangemaakt heeft. Het vraagt uiteraard applicatiefunctionaliteit om dit goed te verwerken. De vraag kan m.i. niet uitsluitend met OOAPI overwegingen beantwoord worden, aangezien hier het poging nummer (in de NL-TEST-ADMIN consumer, dus specifiek OKE) een extra functionele key is die meerdere waarden van (technische key) associationId's veroorzaakt. Dit was nodig omdat er geen 1 op veel relatie is tussen het OOAPI compOffAss en het OOAPI result, maar slechts 1 op 1.

[rrutte]

Als we het hebben over (functionele) keys op een association die van SIS naar TPS gestuurd wordt, zijn dat volgens mij:

• associationId
• offeringId
• personId
• state

De overige attributen zijn eigenschappen van de association waarbij van het TPS het uitgangspunt is dat we (om de integratie zo eenvoudig en eenduidig mogelijk te houden) zo weinig mogelijk verbanden hoeven te leggen tussen de verschillende componentOfferingAssociations.

[hamrt]

Met betrekking tot attemptsLeft spreken we nu af dat het aantal te plannen pogingen door de andere partij gedaan kunnen worden e..g attemptsLeft=1 aangeleverd door het SIS richting TPS betekent dat het TPS nog 1 extra poging mag inplannen. @JosVanderArend deze werkwijze ook opnemen in de documentatie @mcginkel kun jij valideren dat dit ook voor Eduarte zo zou werken?

[JosVanderArend]

Zie #148

[mcginkel]

even terug uit geheugen halen: (het verschil tussen de volgende geldige opties moet wel goed gedocumenteerd worden.)

• attemptsLeft > 0 : er mogen spontaan nieuwe pogingen door TPS geplanned worden en resultaat word in nieuwe association teruggeven die linkt aan bestaande associations. aantal extra pogingen is beperkt tot attemptsLeft
• attemptsLeft == null : er mogen oneindig veel spontaan nieuwe pogingen gedaan worden. steeds nieuwe associations met link naar orginele association (niet vorige, maar originele)
• attemptsLeft = 0 : geen nieuwe pogingen toegestaan

In eduarte moeten we dit nog implementeren, maar met bovenstaande afspraak komen we er wel uit