erinevad sendDocument ebatäpsused

[mbakhoff]

Tere

Mul on mõned küsimused viimase sendDocument speki[1] kohta.

1. päringu väljudi dokis on fault elemendid faultcode, faultstring. äriloogilise vea näites on faultCode, faultString. vist peaks mõlemas suur täht olema?
2. päringu sisendi dokis on documentAttachment tüüp swaRef. kuskil väga ei viidata, mis see tähendab. võiks viidata http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html peale? selle järgi peaks väärtus olema xsd:anyURI, nt cid: protokolliga. näidispäringutes pole cid: prefixi kasutatud, aga peaks? kui cid: prefix on puudu, siis kas peaks ikkagi eeldama, et tegu on cid: protokolliga ja proovima content-id järgi otsida?
3. näidispäringutes on palju imelikku whitespace, nt documentAttachment elemendi väärtus sisaldab reavahetust. osad xml parserid (nt .net XmlReader) ei ignoreeri seda, reavahetus loetakse väärtuse osaks. dhx adapteri testlood selliseid reavahetusi ei sisalda. kas need näited on korrektne sisend, mida peaks toetama?

Lisaks üldise DHX speki[2] otsevõimekuse osa on ebaselge. See ei paista eriti alamsüsteemide olemasolu arvestavat.

1. Asutuse ainus DHX alamsüsteem võib olla nimega DHX*, kus * ei ole tühi. Võib ka olla mitu DHX* alamsüsteemi. Spekk lubab otsevõimekust kontrollida otsese saatmisüritusega "DHX" alamsüsteemile, aga see võib üsna ettearvamatu tulemuse anda.
2. Asutusel võib olla mitu alamorganisatsiooni või infosüsteemi, millest ühel on otsevõimekus ja teine sooviks kasutada vahendamist. Kas see on lubatud? Spekk ütleb, et kui mingi otsevõimekus on olemas, siis ei tohi üldse vahendamist kontrollida. Samas tehniliselt oleks see võimalik, kui vahendatava ja otsevõimekusega osadel on erinev alamsüsteemi nimi.

[1] https://github.com/e-gov/DHX/blob/646aa1d7ca0f2ddc1e9ed60308f494cdff5c745c/docs/sendDocument.md
[2] https://github.com/e-gov/DHX/blob/616c62147f20d3d63619e31ff9471508cf759cef/docs/index.html

[PriitParmakson]

1. SOAP v1.1 (https://www.w3.org/TR/2000/NOTE-SOAP-20000508/) kohaselt faultcode ja faultstring on väiketähtedega. Teie viidatud äriloogilise vea näites on aga kasutatud eraldi nimeruumi http://dhx.x-road.eu/producer. Palun DHX-i praegusel haldajal Vitalil küsimus üle vaadata ja vajadusel parandada, kindlasti aga selgitada.

2. Palun Vitalil vastata.

3. Näidispäringud on GitHub Markdown failis ja läbivad avaldamisel töötluse. Vaatan, et RIA lehelt https://www.ria.ee/dhx/sendDocument ei tule üldse korrektselt lahti. Seetõttu näidispäringutes võib esineda XML-le mittekohast valgeruumi. Protokolli teostamisel tuleks lähtuda seisukohast, et järgmine XML häid praktikaid ise ja eeldame järgimist ka teistelt. Vitali, palun täienda/paranda.

4. "Spekk lubab otsevõimekust kontrollida otsese saatmisüritusega "DHX" alamsüsteemile, aga see võib üsna ettearvamatu tulemuse anda." Saatmiskatse tehakse X-tee protokolli alusel. X-tee protokollides on ju ette nähtud toimimine juhuks, kus adressaat ei ole võimeline saadetist vastu võtma. Kui tulemus on ettearvamatu, siis ei X-tee tehnilisi nõudeid õigesti rakendatud. Sellisel juhul RIA-l on järelevalve õigus ja kohustus. DHX võimekuse kontrollimise võimekus on DHX protokolli sisse võetud selleks, et mitte jäigalt fikseerida keskse registri vajadust. DHX tehti asendamaks varem töötanud Dokumendivahetuskeskus (DVK). Eesmärk oli kaotada keskne lahendus ja minna üle hajusprotokollile. Keskne register (vahendajate register) on siiski tagasi. Kuid peame oluliseks säilitada hajusvõimekust nii palju kui võimalik ja mõistlik.

5. Kui saab saata otse, miks siis otsida veel mingit vahendajat? DHX eesmärk ei ole soodustada olukordi, kus dokumendi saatja peab valima adressaadi erinevate adressaatide ja/või vahendajate vahel. RIA vaatest me muidugi ei suuda ette näha ja tajuda kõiki reaalelulisi vajadusi, mis asutustes võivad tekkida. Seetõttu DHX pakub maksimaalselt lihtsa ja hajutatud, samas siiski praktilise standardse mustri, kuidas asutused saavad dokumente vahetada. See muster näeb ette, et asutusel on üks "postkast", kuhu igaüks võib saata ja kust asutus ise kirjad oma osakondadele edasi marsruudib. Saab muidugi teha keerulisemalt ja see pole keelatud. Asutuste infosüsteemid võivad dokumente saata üksteise vahel mitmesugustel viisidel - kui konkreetsed asutused leiavad, et nii on kasulik ja omavahel kokku lepitakse. Kuid iga asutus peab pakkuma ka standardset DHX teenust.

[VitaliStupin]

1. Tõepoolest SOAP Fault elemendis peab olema faultcode ja faultstring, ning äriloogiline viga sisaldab faultCode ja faultString elemente: https://github.com/e-gov/DHX-adapter/blob/master/dhx-adapter-ws/src/main/resources/dhx.wsdl

2. Tõepoolest sendDocument dokumentatsiooni oleks vaja täiendada DHX teenuse WSDL dokumendiga, milles on kirjeldatud swaRefi kasutamine. WSDL'i näidist saab senikaua võtta siit: https://github.com/e-gov/DHX-adapter/blob/master/dhx-adapter-ws/src/main/resources/dhx.wsdl
   Praegune näide tegelikult ei vasta swaRef spetsifikatsioonile, ning me peame uurima kas praegused DHX protokolli kasutajad tegid nii nagu näeb ette swaRef spetsifikatsioon või nii nagu on tehtud näidises. Tahaks vältida olukorda, et protokoll ja reaalne olukord ei ole kooskõlas.

3. Peab tõdema, et spetsifikatsiooni kirjtaja üritas parandada loetavust, ning selle tulemusena tekitas ebakorrektse näite üleliigsete tühikutega. Lisaks peab uurima miks ria.ee lehel sendDocument leht ei avane korrektselt. Senikaua saab kasutada https://e-gov.github.io/DHX/ ja https://e-gov.github.io/DHX/sendDocument

4. Kuna asutusel spetsifikatsiooni järgi tohib olla mitu X-tee DHX alamsüsteemi, siis dokumendi saatja rakendusel peab olema võimekus valida õige alamsüsteemi. Ainuüksi registrikoodi alusel saaja alamsüsteemi tuvastamine toimib vaid juhul kui saajal on vaid üks DHX alamsüsteem.

5. Spetsifikatsioon ütleb: "Adressaadil otsevõimekuse olemasolul PEAB dokumendi saatma adressaadile otse" (https://e-gov.github.io/DHX/). Me ei saa soovitada spetsifikatsiooni mittejärgimist, isegi kui tehniliselt seda oleks võimalik realiseerida.

[mbakhoff]

Aitäh! Sain oma küsimustele kõik vastused. Võite selle issue kinni panna, kui ei soovi seda punktide 1-3 trackimiseks kasutada

[mbakhoff]

@VitaliStupin leidsin ühe veel: https://e-gov.github.io/DHX/sendDocument "Päringu näide" sendDocument element ei sisalda kohustuslikku elementi DHXVersion

[VitaliStupin]

Dokumentatsioon sai täiendatud, teenuse WSDL lisatud ning https://www.ria.ee/dhx nüüd suunab https://e-gov.github.io/DHX/ lehele.