Beste collega-testers,
Bij het uitvoeren van compliance-testen met EBMS-connecties loop ik tegen een onhandigheid aan waarvan het me handig lijkt als dat wordt opgelost.
De softwarecatalogus vereist dat er voor elke applicatie-versie een apart compliance rapport wordt aangeleverd. In het STP brengen we dit onderscheid aan door voor elke versie een nieuw 'pakket' aan te maken.
Het nadeel van deze werkwijze is dat er ook voor elk 'pakket' een nieuwe EBMS-contract en cpa gemaakt moet worden. Dit is echter niet handig. Het is niet alleen extra werk, het is volgens mij ook overbodig.
- Een ebms-contract beschrijft de connectiviteit tussen twee partijen, en het beschrijft de berichten (actions) die uitgewisseld worden tussen de twee partijen. Het zegt verder niks over applicatieversies waarmee uitgewisselde berichten worden afgehandeld.
- Het aanmaken van een cpa, het inlezen van een cpa en het configureren van de connectie bestaat uit een aantal foutgevoelige handelingen. Handelingen die naar mijn mening overbodig zijn voor het testen van de nieuwe versie van onze applicatie.
- In ons geval hebben wij een digikoppeling met een licentie voor een beperkt aantal connecties. Dit maakt het aanmaken van nieuwe connecties een extra secuur werk. Ook als we oneindig connecties konden aanmaken zou ik het nog steeds onjuist vinden om voor het testen van één berichtversie (jz0101) over dezelfde connectie (Solviteers <-> StUF Testplatform) meerdere digikoppelingverbindingen te hebben.
Voorstel/RFC
Om mee te denken met een oplossing zie ik de volgende werkwijze voor me. Als gebruiker kan ik:
- per berichtstandaard (bijv. jz0101) één EBMS-Contract configureren die de connectiviteit tussen een unieke consumer en een unieke provider beschrijft;
- bij pakketten op het tabblad EBMS Contracts kiezen voor het aanmaken van een nieuw Contract, of het hergebruiken van een bestaand contract.
Groet,
Jarich Ypma
Beste Jarich,
Dank voor je goede suggestie. We gaan uitzoeken of dit mogelijk is voor een volgende release.
Op zich hoef je bij een nieuwe versie niet elke keer een nieuw pakket te configureren. Je kan ook in het bestaande pakket alleen de pakketversie aanpassen. Wanneer er van een eerdere versie al een testrapport is (die je hebt gedownload en in de Softwarecatalogus heb toegevoegd), kan je de versie in StUF Testplatform aanpassen en hierop testen voor een volgende versie van het pakket. Het is dus in principe (vanuit KING/StUF Testplatform/Softwarecatalogus) geen noodzaak voor elke versie van het pakket een nieuw pakket te configureren.
Levert dat ook een werkbare situatie voor je op?
Dag Frank,
De beschreven workaround hebben we nu inderdaad toegepast. Deze workaround komt de overzichtelijkheid overigens niet ten goede.
Het is nu dus kiezen tussen twee kwaden: Of de versie van een bestaand pakket wijzigen met alle nadelen, of voor elke applicatie een nieuw EBMS-contract maken met alle nadelen.
Wij zouden er enorm mee geholpen zijn als dit kan worden opgelost. En ik kan me zo voorstellen dat andere leveranciers hier ook blij van worden.
Groet,
Jarich Ypma
Beste Yarich,
Ik begrijp je wens. Deze realiseren is echter zeker niet eenvoudig en heeft vrij grote consequenties, ook voor leveranciers of pakketten die niks met EBms doen.
Leveranciers kunnen verschillende softwarepakketten hebben die ook parallel getest (moeten) kunnen worden. Deze mogelijkheid is op verzoek van verschillende leveranciers van softwarepakketten aan het StUF Testplatform toegegoegd.
Daarvoor moet het StUF Testplatform binnenkomende berichten kunnen routeren naar de gewenste test (voor een specifiek pakket). Daarom is de url waarop het StUF Testplatform binnenkomende berichten ontvangt verschillend voor elk pakket. Deze url zit opgenomen in het EBms contract. Het gevolg daarvan is dat het EBms contract nu niet herbruikbaar is over verschillende pakkettenconfiguraties.
We onderzoeken of het mogelijk is toch een oplossing (om de genoemde beperking heen) te bedenken.