Bij het verwerken van een soapfault van het testplatform valt me op dat het proces in onze servicebus met enige regelmaat crasht. Dit in tegenstelling tot de gebruikelijke werking van de servicebus bij een soapfault.
Na wat onderzoek blijkt dat onze servicebus de faultcode en de faultstring niet kan vinden in de soapfault van het STP. Probleem is dat de STP-soapfault in sommige situaties de elementen faultcode en faultstring prefixt met de namespace van de soapenvelop (http://schemas.xmlsoap.org/soap/envelope/). Volgens de soap-envelop specifcaties (http://schemas.xmlsoap.org/soap/envelope/) is dit echter niet de bedoeling. Hier wordt de namespace http://www.w3.org/2001/XMLSchema voorgeschreven.
De situaties waarin dit gebeurt:
- Als er geen actief testscenario is om te matchen
- Wanneer er een actief testscenario is, maar het voorgeschreven scenario niet gevolgd of gevonden kan worden
Doordat de onjuiste namespace gebruikt wordt, denkt de faulthandler van de servicebus dat de faultcode en faultstring leeg zijn. Dit zijn echter verplichte velden, vandaar dat het proces van de servicebus crasht. Volgens mij is in dit geval niet de werking van de servicebus het probleem, maar de soapfault van het STP die de soap-envelop regels niet juist heeft geïmplementeerd. Bij soapfaults als gevolg van een invalide xml klopt het formaat namelijk wel.
- Delen jullie de analyse dat het STP de soapfault in bovenstaande situaties niet conform de w3c-standaard implementeert?
- Zo ja, kan dit opgelost worden? Voorgestelde oplossing: faultcode en faultstring prefixen met de juiste namespace (http://www.w3.org/2001/XMLSchema)
Groet,
Jarich Ypma
We hebben in release 1.11.0 van het StUF Testplatform de manier waarop fouten worden teruggegeven aangepast. In de beschreven situatie komt de volgende soap fault:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<env:Fault>
<faultcode>env:Client</faultcode>
<faultstring>STP00125</faultstring>
<detail>Active execution isn't found. Application:[id=50103250].</detail>
</env:Fault>
</env:Body>
</env:Envelope>
Er zit hier dus geen envelope namespace (meer) in faultcode en faultstring. Naar mijn idee is dat een valide invulling van faultcode en faultstring.