Miksi skeemavalidointi ei riitä?

Yleinen uskomus on, että XML-aineisto on kunnossa, kun se kattaa sanoman rakennekuvauksen (skeema) asettamat vaatimukset. Tämä on täysin virheellinen käsitys!

Seuraavassa asia on havainnollistettu esimerkin avulla. Alla on laskun kuva, joka on muodostettu Finvoice-sanomasta, joka on rakennekuvauksen mukaan validi eli kunnossa. Kuten näet, lasku ei sisällä lainsäädännön tai käytännön edellyttämiä tietoja tai ylipäänsä juuri mitään tietoja. Rakennekuvauksen mukaan pakollisia tietoja on vähän ja pakollisiksi määritellyt elementit voidaan jättää tyhjäksi tai niiden sisältö voi olla virheellistä, puutteellistä tai ristiriitaista.

Laskun kuva:

Laskun XML-rakenne (Finvoice 3.0):

<?xml version="1.0" encoding="ISO-8859-15"?>
<Finvoice Version="3.0">
  <SellerPartyDetails>
    <SellerOrganisationName>  </SellerOrganisationName>    
  </SellerPartyDetails>
  <BuyerPartyDetails>  
    <BuyerOrganisationName>  </BuyerOrganisationName>
  </BuyerPartyDetails>
  <InvoiceDetails>
    <InvoiceTypeCode> INV01 </InvoiceTypeCode>
    <InvoiceTypeText> </InvoiceTypeText>
    <OriginCode> Original </OriginCode>
    <InvoiceNumber> </InvoiceNumber>
    <InvoiceDate Format=" CCYYMMDD "> 00000000 </InvoiceDate>
    <InvoiceTotalVatIncludedAmount AmountCurrencyIdentifier=" xxx "> 00 </InvoiceTotalVatIncludedAmount>
  </InvoiceDetails>
  <InvoiceRow>
  <!-- no mandatory elements on a line level -->  
  </InvoiceRow>
  <EpiDetails>
    <EpiIdentificationDetails>
      <EpiDate Format=" CCYYMMDD "> 00000000 </EpiDate>
      <EpiReference />
    </EpiIdentificationDetails>
    <EpiPartyDetails>
      <EpiBfiPartyDetails>
      </EpiBfiPartyDetails>
      <EpiBeneficiaryPartyDetails>
        <EpiAccountID IdentificationSchemeName=" BBAN "> 0 </EpiAccountID>
      </EpiBeneficiaryPartyDetails>
    </EpiPartyDetails>
    <EpiPaymentInstructionDetails>
      <EpiInstructedAmount AmountCurrencyIdentifier=" yyy "> 00,00 </EpiInstructedAmount>
      <EpiCharge ChargeOption=" BEN "/>
      <EpiDateOptionDate Format=" CCYYMMDD "> 00000000 </EpiDateOptionDate>
    </EpiPaymentInstructionDetails>    
  </EpiDetails>
</Finvoice>

Mistä ongelma johtuu?

Rakennekuvauksen (W3C XML Schema) tehtävänä on kuvata XML-sanoman sallittu rakenne. Sen ilmaisuvoima ei riitä laskennallisten muotovaatimusten (IBAN, BIC, y-tunnus, OVT, maksuviite) eikä eheysvaatimusten (summat, päivämäärien suhde toisiinsa, muut ehdollisuudet) kuvaamiseen.

Samalla rakennekuvauksella halutaan usein myös kattaa useita sanomatyyppejä (kauppalasku, hyvityslasku, tilaus, etc.), toimialatarpeita ja käyttötapauksia. Tällöin lähes kaikki tiedot joudutaan asettamaan skeemassa vapaaehtoisiksi, koska lähes aina löytyy tapaus, jossa kutakin tietoa ei voida asettaa pakolliseksi. Tällöin skeeman rooliksi jää "pelikentän" rajaaminen ja pelin säännöt tulee kuvata sekä tarkistaa muulla tavoin.

Miten ongelma ratkaistaan?

Ehdolliset pakollisuudet, monimutkaiset muotovaatimukset ja erilaiset eheysvaatimukset voidaan kattaa sääntötarkistuksilla.

Oman testauspalvelun rakentaminen on harvoin järkevää, koska ratkaisun kehittäminen ja ylläpito nielisivät säästetyt resurssit. Truugon ajatuksena on tarjota yleinen testauspalvelualusta, jolloin organisaatioiden vastuulle jää vain testipenkkien laadinta.

Truugo-portaalissa käyttäjät voivat laatia, julkaista ja jakaa omia testipenkkejä (testausprofiileja), jotka kattavat sekä skeemavalidoinnin että sääntötarkistukset. Loppukäyttäjän (testaajan) ei tarvitse kuin ladata sanoma palveluun saadakseen välittömästi kattavan ja selkokielisen palautteen.

Miten saan palvelun käyttööni?

Aloituskynnys voisi tuskin olla enää matalampi, sillä voit rekisteröityä ja tutustua palveluun maksutta ja sitoumuksetta. Palvelu tarjoaa muutamia demotestipenkkejä (testausprofiileja), joiden avulla pääset tutustumaan palvelun toimintalogiikkaan tarkemmalla tasolla.

Helpointa on ottaa Truugo aluksi omaksi työkaluksi. Kun olet vakuuttunut palvelun hyödyistä, on Truugo vaivatta laajennettavissa oman tiimin apuvälineeksi sekä itsepalveluksi kumppaneille.