Zmatený ISDS

13.12.2010 22:56 | Přečteno: 2192×

Přidávám do knihovny libisds funkce implementující nové služby, které zavedl Provozní řád ISDS vydaný 28. listopadu 2010 (velký archiv ZIP) a opět se nestačím divit.

Ne, dnes nejde o bezpečnostní chybu. Jen o ukázku kvalitní dokumentace a kvalitní implementace.

Konkrétně služba GetMessageStateChanges umí vrátit seznam změn stavů odchozích zpráv (například dodána, doručena, nelze doručit). Na vstup se uvede rozpětí času a na výstup vyleze (prázdný) seznam změn.

Rozpětí času se zadává jako počáteční a koncový čas ve formátu ISO, každý do vlastního elementu – dmFromTime a dmToTime.

Specifikace (provozní řád) nabízí podobnou službu, která ale vrací celé obálky datových zpráv, což je těžkopádné a pomalé. Na druhou stranu interval může být otevřený (i z obou stran). Dnes probíraná služba na hrátky s časem jde od lesa:

Časový interval zadaný na vstupu musí ležet v nepříliš vzdálené minulosti (v současné verzi 15 dnů). Starší události se evidují pouze „starým“ způsobem, ne tedy pomocí této WS.

A sice přímo nepřipouští, že by interval mohl být otevřený, nicméně v XML schématu uvádí, že oba elementy mohou být prázdné:

<xs:complexType name="tGetStateChangesInput">
  <xs:sequence>
    <xs:element name="dmFromTime" nillable="true" type="xs:dateTime">
      <xs:annotation>
        <xs:documentation>čas dodání od</xs:documentation>
      </xs:annotation>
    </xs:element>
    <xs:element name="dmToTime" nillable="true" type="xs:dateTime">
      <xs:annotation>
        <xs:documentation>čas dodání do</xs:documentation>
      </xs:annotation>
    </xs:element>
  </xs:sequence>
</xs:complexType>

A tak jsem si řekl, že za zkoušku nic nedám. Zkusil jsem takto službu GetMessageStateChanges zavolat:

<?xml version="1.0"?>
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
  <Body>
    <GetMessageStateChanges xmlns="http://isds.czechpoint.cz/v20">
      <dmFromTime/>
      <dmToTime/>
    </GetMessageStateChanges>
  </Body>
</Envelope>

A knihovna mi vynadala, že v odpovědi serveru chybí návratový kód volání. Návratový kód je běžně uschován v podstromu /Envelope/Body/*/dmStatus, tentokrát ale byl jinde:

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <SOAP-ENV:Body>
    <q:GetMessageStateChangesResponse xmlns:q="http://isds.czechpoint.cz/v20" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <q:dmRecords>
        <q:dmStatus>
          <q:dmStatusCode>9005</q:dmStatusCode>
          <q:dmStatusMessage>Internal error</q:dmStatusMessage>
        </q:dmStatus>
      </q:dmRecords>
    </q:GetMessageStateChangesResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Pro porovnání ukázková odpověď z dokumentace:

<?xml version="1.0"?>
<q:GetMessageStateChangesResponse xmlns:q="http://isds.czechpoint.cz/v20" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <q:dmRecords>
    <q:dmRecord>
      <q:dmID>169100</q:dmID>
      <q:dmEventTime>2010-10-11T11:18:17.308+02:00</q:dmEventTime>
      <q:dmMessageStatus>4</q:dmMessageStatus>
    </q:dmRecord>
    <q:dmRecord>
      <q:dmID>169100</q:dmID>
      <q:dmEventTime>2010-10-11T11:18:23.249+02:00</q:dmEventTime>
      <q:dmMessageStatus>6</q:dmMessageStatus>
    </q:dmRecord>
  </q:dmRecords>
  <q:dmStatus>
    <q:dmStatusCode>0000</q:dmStatusCode>
    <q:dmStatusMessage>Provedeno &#xFA;sp&#x11B;&#x161;n&#x11B;.</q:dmStatusMessage>
  </q:dmStatus>
</q:GetMessageStateChangesResponse>

Jak můžete vidět, kód se lepí i jinde než jen ve studentských projektech.

A nakonec ještě jeden vtip ze specifikace

Systémové datové zprávy:

9

Trvalé znepřístupnění schránky typu PFO, PO, PO_ZAK, OVM, OVM_NOTAR, OVM_EXEK při ukončení činnosti nebo výmazu z evidence.

10

Dočasné znepřístupnění schránky typu FO a PFO z důvodu úmrtí majitele DS, zjištěné z ISEO při doručení datové zprávy fikcí.

Zajímalo by mě, kdy je podle autorů specifikace fyzická osoba dost mrtvá na to, aby její datová schránka byla znepřístupněna trvale, na rozdíl od schránky osoby právnické, jejíž činnost byla ukončena.

       

Komentáře

[Luk]

Zajímalo by mě, kdy je podle autorů specifikace fyzická osoba dost mrtvá na to, aby její datová schránka byla znepřístupněna trvale

Třeba je to připraveno pro reinkarnaci. Nebo pro návrat (oživlé mrtvoly) ze záhrobí

[kkaarreell]

Mrtvi lide jiz davno sponzoruji politicke strany. Pozadavek, aby mohli opet prijimat "postu", je naprosto legitimni.

[Jirka]

Na tu specifikaci úmrtí určitě bude nějaká Euro norma.

[xkucf03]

BTW: proč je to API není psané česky? To si vážně někdo myslí, že DS jsou tak geniální systém, že se ho podaří někdy exportovat do anglicky mluvících zemí? Nebo aspoň nějakých jiných zemí? Nebo je v plánu outsourcování vývoje do levné Indie? Od projektu (za)vedeného státem bych spíš čekal podporu domácí zaměstnanosti.

[rADOn]

Protoze si kdokoliv muze nechat udelat implementaci kdekoliv? Protoze to muzou chtit pouzivat firmy sidlici jinde v unii?

[xkucf03]

Tak by si na to právě mohli najmout české firmy/vývojáře. Přijde mi to jako lepší politika než cpát někomu peníze (dotace, granty) atd. – pokud se tedy nějaká hospodářská politika má dělat (zatím to rozhodně nevypadá, že by se české vlády chtěly vzdát zásahů do ekonomiky a nedělat hospodářskou politiku resp. nezasahovat).

[rADOn]

Vnucovat se takovymhle zpusobem jde proti volnymu obchodu v unii. Sice se to mistnim nackum nelibi, ale ma to smysl. Ja mam taky API od polaku v anglictine, a zaplatpambu za to.

[Kvakor]

Já bych se naopak dost divil, kdyby to bylo česky. U bohů, je to přece API, běžní uživatelé se k tomu nedostanou a opravdovým programátorům angličtina nevadí, spíš naopak. A navíc, dokážete si předstasvit, jak takový napůl český (resp. 'cesky') a napůl anglický SOAP vypadá obludně?

[Filip Jirsák]

Problém je, že pro specificky české věci často neexistují odpovídající anglické termíny. Takže programátoři si pak vymýšlejí různé podivuhodné překlady, a API pak není ani v angličtině, ale v něčem, co jen jako angličtina vypadá (asi jako „So Far“ z Limonádového Joe).

[Rezza]

Ty jo, nestras. Ono to klidne mohlo nejakeho genia z DS napadnout :D

[12345]

Hm, tak na tohle bych asi neměl nervy…

Jen matematická: zmátla mě řeč o otevřeném intervalu. Zřejmě byl míněn interval neomezený. Když je jen otevřený, stále ještě může být omezený.

[petr_p]

Tak jsem si vyzkoušel ukázkový scénář, kdy jsem odeslal zprávu, druhá strana si ji přečetla, a pak se touto službou zeptal na změny stavů za posledních deset dní (oba časy jsem vyplnil) a stejně server vrací prázdný seznam. Nějak jim to nefunguje.

[petr_p]

Ráno už se služba k doručené zprávě znala. Asi to není tak rychlé, jak bych si představoval.

[msk]

Je to zhruba rok co som vyvijal komercny connector do tejto sracky a tych nadavok co lietali po kancelarii bolo neurekom. Ono ten interface nie je zlozity, ten interface je uplne debilny, ako keby ho navrhol uplny magor. Na druhu stranu k prihliadnutiu k charakteru celeho projektu ( ukradnut dalsie miliardy z rozpoctu do spriatelenych firiem a nejak vykazat cinnost aby sa nepovedalo ) to mohlo dopadnut este horsie ( teda v ramci podmienok CR/SR, v normalnej krajine by to uz asi bolo za hranicou unosnosti ).

[Luk]

v normalnej krajine by to uz asi bolo za hranicou unosnosti

I v "normálních zemích" to občas trochu skřípe

[petr_p]

Vývojáři odpověděli, že chybu opravili a spravenou verzi nasadí 19. prosince.

Dále prozradili, že nedefinované hraniční časy ve smyslu neomezeného intervalu budou podporovány a že se o tom zmíní ve specifikaci. Na otázku, zda výstupní seznam záznamů je seřazen, řekli, že nikoliv.