1. Milieuklacht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Handleiding opladen XML in mkros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Werken met Refertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Milieuklacht Handleiding opladen XML in mkros Klacht Opname Introductie Zakelijk Omschrijving Functioneel Ontwerp Precondities Opladen menu Opladen milieuklacht feedback Business Logica niet gedefiniëerd door XSD-schema Opvolgstappen Foutmeldingen Werken met refertes
Klacht Opname Introductie MKROS is de toepassing die instaat voor de opvolging van de milieuklachten ingegeven door de lokale milieuambtenaren. Ondanks een moeilijke jeugd heeft het gebruik van de toepassing een hoge vlucht genomen en is de satisfactiegraad behoorlijk. Een aantal gemeenten gebruiken een eigen toepassing om milieuklachten te beheren. Deze wensen een export op te laden in het centrale mkros systeem, het doel van deze uitbreiding.
Zakelijk Omschrijving Dit document beschrijft hoe het opladen van een xml bestand of een archief in zip formaat van xml bestanden naar MKROS. Elk xml bestand bevat een Document van het type Dossier. De definitie ervan is te vinden in MilieuklachtDataTypes.xsd. De gebruiker zal via een gewone file upload (xml of zip) de bestanden aanleveren. Na verwerking toont de toepassing een pagina met een lijst van al dan niet geladen bestanden en bij niet-laden de fouten of reden waarom. Bij het verwerken wordt de aanlevering afgepunt ten opzichte van de inhoud van de databank. Verschillen en toevoegingen worden opgenomen. Als er geen verschillen (of toevoegingen) zijn, mogen er geen database updates uitgevoerd worden. Dus herhaalde aanbieding is mogelijk.
Functioneel Ontwerp Hieronder een grafische voorstelling van de te volgen stappen bij het opladen in MKROS.
Precondities De gebruiker is geauthenticeerd en heeft het recht om milieuklachten op te laden. Indien niet krijgt die geen opladen-menu te zien. Het Opladen scherm komt meteen in het hoofdmenu. Het bestaat uit slechts twee lijnen.
Opladen menu In het hoofdmenu ziet de gebruiker een submenu 'Opladen van milieuklachten'. Via de Browse of Selecteer-knop kan de gebruiker een bestand selecteren op zijn lokale omgeving. Door vervolgens op opladen te klikken wordt het bestand opgenomen door MKROS. De gebruiker kan .xml of .zip van .xml bestanden aanleveren. Ingevalle een zip mogen de xml bestanden niet in subfolders zitten.
Opladen milieuklacht feedback Na het klikken op de knop 'Opladen' zal een feedback pagina verschijnen. De wachttijd hierop is afhankelijk van de grootte van het bestand en de upload-snelheid. De gebruiker kan een van vier mogelijke reacties krijgen: technisch probleem binnen mkros validatie problemen xml-bericht overtredingen milieuklacht specificaties succesvol verwerkt bericht en of het gaat om een nieuw dossier of een bijwerking. Bij een zip bestand krijgt de gebruiker een feedback lijst bestaande uit een combinatie van bovenstaande 4 meldingen, elk geplaatst bij het xml bestand, zoals hieronder (onafgewerkt) afgebeeld:
De titel bevat de naam van het bestand en het moment waarop de opname gestart is. De kolommen bevatten respectievelijk de naam van het xml bestand, de referte van de aanleverende miliedienst, de referte van MKROS, en het resultaat van het opladen. De MKROS-referte is klikbaar en leidt naar het dossier in MKROS. De illustratie toont de mogelijke gevallen: 12345678.xml: goed en nieuw dossier 12345679.xml: geen xml bestand 12345680.xml: xml doch onleesbaar (niet interpreteerbaar) 12345681.xml: leesbare xml doch invalide 12345682.xml: leesbaar en valide doch zondigt tegen de specificaties 12345683.xml: goed en update aan bestaand dossier De gebruiker kan vervolgens met de knoppen bovenaan terug naar het hoofdmenu. Indien gewenst klikt de gebruiker op 'Exporteer als werkblad'. De toepassing levert dan een csv bestand af met de inhoud van de pagina, de MKROS referentie is niet klikbaar. Bij een individuele xml komt slechts één lijn in de tabel en bevat de hoofding de xml bestandsnaam in plaats van de zip.
Business Logica niet gedefiniëerd door XSD-schema Opvolgstappen Bij het doorsturen van de OpvolgStappen, moet minstend de registratie (<StapEnType>registratie - registratie van de klacht) als opvolgstap gedefiniëerd zijn.
Foutmeldingen Er wordt getracht een zo goed mogelijke foutmelding te geven als er een semantische fout in de xml staat. Indien er zich een technische fout voordoet, dan wordt er een uniek nummer gegenereerd voor deze fout. Dit nummer wordt aan de gebruiker aangeboden zodat hij eventueel de beheerder op de hoogte kan brengen van de fout. Met dit nummer kan de fout worden gelokaliseerd in de logging en kan er gekeken worden wat er is misgegaan en een oplossing zoeken voor de fout.
Werken met refertes Algemene uitleg 'Werken met Refertes' Op verschillende plaatsen in de xml is er een element Referte opgenomen. Dit element heeft als doel om een item voor elke partij uniek te kunnen definiëren. (bv een klacht kan een MKROS referte hebben en een KLANT referte, de MKROS referte wordt dan gebruikt om de
klacht uniek binnen MKROS te kunnen identificeren, terwijl dat de KLANT referte door de klant gebruikt wordt om de klacht binnen zijn systeem uniek te kunnen identificeren). Door de structuur van de Referte is het niet mogelijk om deze verplicht af te dwingen via het schema (bij het attribuut naam kan om het even welke string worden ingevuld en men kan in het schema niet zeggen dat bv de referte met naam MKROS verplicht is, dit kan alleen door validatie in de code gebeuren). Hieronder volgt een opsomming van refertes in de XML die door de applicatie gebruikt worden: Element
Referte type
Extra informatie
Dossier
Referte MKROS
verplicht indien het om een update gaat: bevat de id die het dossier bepaalt, indien deze id referte niet wordt meegegeven, zal ervan uitgegaan worden dat het om een nieuw dossier gaat. Er zal een id gegenereerd worden voor dit dossier dat bij updates kan gebruikt worden. Wanneer de referte niet bestaat, dan wordt ervan uitgegaan dat dit een nieuw dossier is en zal een nieuw dossier aangemaakt worden met dit id. (referte id moet numeriek zijn)
Dossier->Beheerder
Referte MKROS
verplicht: bevat de id van de milieudienst die beheerder is van de klacht
Opvolgstap
Referte MKROS
optioneel, bij een bestaand opvolgstap kan de huidige referte meegegeven worden, dan wordt de opvolgstap geupdate, indien geen referte wordt meegegeven, dan wordt een nieuwe opvolgstap aangemaakt. (numeriek)
OpvolgStap->Milieudienst
Referte MKROS
verplicht: bevat de id van de milieudienst die de huidige opvolgstap heeft volbracht (numeriek)
Klacht
Referte MKROS
optioneel, bij een bestaand klacht kan de huidige referte meegegeven worden, dan wordt de huidige klacht geupdate, indien geen referte wordt meegegeven, dan wordt een nieuwe klacht aangemaakt. (numeriek)
Klacht
Referte LNE
optioneel, bevat de code van de klacht (bv zelfbouwmarkt) (alfanumeriek)
Klager
Referte MKROS
optioneel, bij een bestaande klager kan de huidige referte meegegeven worden, dan wordt de huidige klager geupdate, indien geen referte wordt meegegeven, dan wordt een nieuwe klager aangemaakt (numeriek)
VermoedelijkeVeroorzaker->Identificatie
Referte MKROS
optioneel, bij een bestaande VermoedelijkeVeroorzaker kan de huidige referte meegegeven worden, dan wordt de huidige VermoedelijkeVeroorzaker geupdate, indien geen referte wordt meegegeven, dan wordt een nieuwe VermoedelijkeVeroorzaker aangemaakt (numeriek)
WerkelijkeVeroorzaker->Identificatie
Referte MKROS
optioneel, bij een bestaande WerkelijkeVeroorzaker kan de huidige referte meegegeven worden, dan wordt de huidige WerkelijkeVeroorzaker geupdate, indien geen referte wordt meegegeven, dan wordt een nieuwe WerkelijkeVeroorzaker aangemaakt (numeriek)
Werken met Refertes Waarom Refertes in XML Refertes in Databank Refertes in Java
Waarom Bij het uitwisselen van gegevens tussen diverse belanghebbenden of partijen, kunnen elementen gebruikt bij de uitwisseling voor elke partij een verschillende identificatie hebben. Zo bevat bijvoorbeeld elke professionele correspondentie een uw/mijn referte aanduiding. Het referte systeem hier voorgesteld is een eenvoudig middel om de identificatie van verschillende belanghebbenden te koppelen met eenzelfde entiteit of ding in de realiteit. Binnen ACD gebeurt dit door middel van een referte. Een referte is een uniek label dat een partij in een transactie aan een element geeft. Hierbij gelden de volgende regels: Refertes gekoppeld aan een element of entiteit zijn ondubbelzinnig aan één partij te koppelen. De indentifier waarmee refertes aan eenzelfde partij gekoppeld worden kunnen wel verschillen over elementen. Deze koppeling kan absoluut zijn, waarbij de partij geidentificeerd wordt door middel van de naam, of relatief, volgens de rol van de partij in het document, zoals 'AFZENDER' en 'ONTVANGER'. In dat geval wordt de PARTIJ op een andere manier ondubbelzinnig geïdentificeerd. De waarde van de referte bestaat uit een reeks van alfanumerieke gegevens. Refertes zijn niet verplicht, maar indien deze gedefinieerd zijn, mogen ze niet leeg zijn. Refertes hebben een verwijzing naar een partij, deze verwijzing is verplicht. Alle mogelijke partijen zijn vooraf vastgelegd tussen de participanten van de uitwisseling. Elke participant heeft een set partijen
waarvan de refertes ingevuld of aangepast kunnen worden. Partijen die niet tot deze set behoren worden ongewijzigd behouden in het bericht. Bijvoorbeeld, als in een communicatie tussen LNE en OVAM een referte van VMM voorkomt, zullen beide LNE en OVAM deze ongewijzigd laten. Het is aangewezen om, indien het element in een uitgaand bericht gestuurd wordt, de relevante refertes toe te voegen. Eenzelfde partij kan meerdere refertes hebben voor hetzelfde element Refertes zijn niet universeel, doch beperkt tot de toepassing die bovenstaande specificaties afdwingt.
Refertes in XML Refertes worden in XML eenvoudig weergegeven door het volgende element:
2403323569 Er wordt steeds de naam Referte gebruikt voor het element. Het element heeft steeds de volgende Type definitie (uit het generieke schema):
<xs:complexType name="ReferteType"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="naam" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="1"/>
Er kunnen meerdere refertes aan een element toegewezen worden. Dus het gebruik ervan is telkens als volgt:
<xs:complexType name="DossierType"> <xs:sequence> <xs:element name="Referte" type="generiek:ReferteType" minOccurs="0" maxOccurs="unbounded" > <xs:annotation> <xs:documentation> De referte waarmee het KachtDossier geidentificeerd wordt. Zie de algemene discussie over refertes voor meer details. ...
Er worden geen constraints gedefinieerd op het type. Het afdwingen van verdere specificaties is geheel de verantwoordelijkheid van de ontvangende toepassing; Hierin hebben we aftoetsen mogelijke geldige partijen. aftoetsen mogelijke vormen of patronen van refertes. al dan niet opnemen van ontvangen refertes. Welke refertes zijn betrouwbaar en welke niet? Als een bedrijf een OVAM referte toevoegen aan een bericht, is dat dan betrouwbaar? heruitsturen van ontvangen refertes. Het kan zijn dat bepaalde refertes niet uitgestuurd mogen worden afhankelijk van het bericht en de bestemmeling.
Refertes in Databank Refertes kunnen gebruikt worden om een kruispunt databank of zelfs een repertorium op te bouwen. Bij een kruispunt databank worden de refertes van dezelde entiteit gekoppeld met elkaar zodat kruisverwijzingen mogelijk zijn. Hier worden, aan de hand van een refertes en een entiteit de ander refertes opgehaald. Bij een repertorium worden de refertes opgeslagen zodat deze met een zoek-opdracht opgehaald kunnen worden en leiden naar de elementen naar welke ze verwijzen. Hier worden entiteiten opgehaald aan de hand van hun referte, die een patroon matcht. Element types worden best niet opgeslagen met hun naam daar die meestal lang kunnen worden en weinig uniek zijn, dus bij indexering niet de ideale performantie verschaffen.
Refertes in Java Hash van de FQN (Fully Qualified Name) of interface naam gebruiken als entiteit id.
