Uit welke onderdelen is het statuspanel opgebouwd?

 Het statuspanel bestaat uit de volgende onderdelen:

• ANAL
  Analyseren tabellen op fouten en deze herstellen
  (Is onderdeel van de ochtend run)
• ANTW.VERW.AGENDERING 
  De voor vandaag geplande publicaties van Antwoordproducten worden geactiveerd 
  (Is onderdeel van de ochtend run)
• ARCHIEF
  Controle of er bewaarplaatsen toegevoegd moeten worden en stukken verplaatst moeten worden.
  (Is onderdeel van de ochtend run)
• ARCHIEF.BEVRIEZEN
  Bevriezen dossier na beoordeling of x dagen na afhandelen zaak
  verwerking "eerste nacht": koppelen document-versies aan dossier.
  verwerking "tweede nacht": documenten converteren naar pdf 
  verwerking "derde nacht": aanmaken en opslaan zaakxml. 
  (Is onderdeel van de ochtend run)
• ARCHIEF.KMCHK
  Logging voor de "kenmerken check" van de archiefprocedure
  (Is onderdeel van de ochtend run)
• AWS.UPLOAD
  De status en aantallen van documenten worden getoond waarbij de upload is fout gegaan. Tevens de mogelijkheid om net als bij de ETL procedure te klikken waarbij een scherm met een lijstje van de documenten die hersteld kunnen worden en welke niet. Met ‘Herstel’ wordt de herstelactie uitgevoerd.
• BETALING
  Internetkassa betalingen en de status hiervan worden gelogd
  (Zie ook koppeling betaling met niet gestarte hoofdzaak)
• BLOBVERWIJDERD
  Verwijderen van document blob records, bijvoorbeeld ongebruikte gereserveerde blob-id bij toevoegen document via de Office macro en mail plugin. Ook bij nieuwe versie van een document, dan wordt de blob verplaatst naar de tabel DOCUMENTBLOB_HISTORY. Oude Twitter documenten worden ook verwijderd
• BSB.VERW.AGENDERING
  De voor vandaag geplande publicaties van beslisbomen worden geactiveerd
  (Is onderdeel van de ochtend run)
• DEBUG
  De algemene onderhoudsfunctie die gebruikt wordt om te bepalen of een programma goed werkt.
• DOC.NAAR.FS - Dit is de logging voor document offloading (indien ingesteld)
  Niet verplaatste documenten naar fileserver melding is nu een WA (geel) melding *
• DOSOVERBRENGING
  Logging van het overbrengen van zaakdossiers en documenten als onderdeel van de Archief overbrengingsprocedure.
• DOSVERNIETIGING
  Logging van het vernietigen van documenten als onderdeel van de Archief vernietigingsprocedure. Als een document op manier 1 niet verwijderd kan worden, probeert ie het op manier 2. Etc. Zo zijn er meerdere manieren om een document te verwijderen. Pas als alles mislukt wordt het getoond in de tijdlijn.
• DROPBOX
  Dit is de logging van de uitwisseling naar dropbox. In de 4e kolom kun je klikken op “Dropbox-distributie”. Daar zie je een overzicht van de personen waarbij een fout is opgetreden. Met R kun je het aantal fouten resetten nadat een probleem is hersteld (zoals een mislukte authenticatie) waardoor het weer opnieuw geprobeerd wordt. (als de teller op 10 staat stopt het proberen). Met de X wordt de teller op 10 gezet en stopt de distributie.
  In de laatste kolom staat het aantal fouten. Door hierop te klikken zie je een gedetailleerd verslag van de distributie alsof je die medewerker bent.

• Extract - Tanslate – Load (ETL) - via de ETL procedure kunnen de gegevensmagazijn onderdelen en registraties worden gevuld. Door te klikken op de naam van het ETL onderdeel (4e kolom) wordt de log van de import getoond. Door te klikken op het [naam] extract > kan handmatig een bronbestand geladen worden, als 'test' of als definitieve 'laad'. Uiteraard kan deze procedure ook geautomatiseerd worden opgestart, bijvoorbeeld via wget met onderstaande URL.
  [a href="https://xxx/mozard/!mozard.suite63.scherm[/a],
  De vijf verschillende ETL procedures zijn:
  - ETL_ADRES = De officiële adressen in te lezen via CSV bestand
  - ETL_BEDRIJF = De bedrijven en instellingen in te lezen via CSV bestand
  - ETL_BURGER = Uittreksel van het GBA in te lezen via CSV bestand
  - ETL_KADPERCEEL = De kadastrale percelen in te lezen via CSV bestand
  - ETL_OBJECT = Overige objecten in te lezen via XML bestand

• FEEST
  De feestdagentabel deze job telt het aantal opgevoerde feestdagen in de toekomst (en geeft een melding als het waarschijnlijk is als de beheerder deze tabel aan moet vullen. De tabel is gevuld tot en met 2029 via een update)
  De tabel wordt gebruikt voor de berekening van het aantal werkdagen(doorlooptijd), bij reserveringen en het niet aanmaken van scan directory's op deze dagen.
  (Is onderdeel van de ochtend run)
  
• KOPPELVLAK
  Koppelvlak verwerkingen voor inkomende en uitgaande API's 
  Voorbeeld inkomend koppelvlak is PDFen zaak/inlogcode: 16112/pdfen
  (zie ook zaken binnenkomend koppelvlakverzoek)
  
• LOGIN - meldingen van verkeerde inlogpogingen vermeld.
  (alleen van toepassing bij Mozard formulier login en niet voor SAML/SSO)
  Mislukt en tijdelijk geblokkeerd zijn nu een WA (geel) *
  
• MAIL
  Met een klik op MAIL wordt de log van de mailberichten binnenkomende en uitgaande mailberichten getoond. Via ‘Wachtrij weergeven >’ worden de (nog) niet verzonden mailberichten getoond. Dit wordt veelal veroorzaakt omdat het e-mail adres ongeldig is. Oude niet verzonden mail berichten kunnen via de X rechts in de mailregel verwijderd worden . Via de R rechts in de mailregel kunnen de verzendfouten (10) gereset worden.
  (Zie aparte uitwerking over Mozard mail )
  
• MOZA - avondrun
  Procedure MOZSYSAVONDRUN, elke avond om 19u01
  -check publicate zaken
  -chek vervaldatum zaken
  -herbereken doc-size waar nodig
  -vrijgeven gelockte, maar niet verwerkte scan records
  -"scherm0900" en "scherm0901" (Scanvelop en Postintake)
• MOZM - minutenrun 
  Deze draait alle dagen, elke 5 minuten tussen 6:00 uur en 22:00 uur. Deze synchroniseert alle oracle text-indexen op een paar uitzonderingen na (zie volgende alinea/job). Tevens verzorgt deze job het:
  - verzenden van email
  - verzenden van sms berichten.
  - verzenden van statussignalering berichten
  De procedure/job MOZSYSMINUTENRUN met parameter Fulltext='J', is een aparte job. Deze synchroniseert de grote (qua omvang) oracle text-indexen en voert taken uit die wat langer kunnen duren. Deze job is express los van de "normale" minutenrun omdat deze langere tijd kan lopen. Door de taken te splitsen lopen de zaken van de "normale" minutenrun geen vertraging op.

• de taken die de minutenrun job uitvoert zijn onder andere:
  - ophalen van tweets en newsfeeds (indien geconfgureerd)
  - synchroniseren van oracle-text-indexen :
  - mozdocindex (tabel documentblob)
  - docflesys_fulltext_index (tabel document-flesystem: scandocumenten)
  - generiek_zoeken en generiek_zoeken_ii (ten behoeve van de generieke zoekfuncionaliteit)
  - verwerken van documenten die naar pdf omgezet moeten worden
  - verspreiden van documenten naar dropbox (indien geconfgureerd)
  - verwerken van aangepaste zoeksleutels bij antwoord producten
• MOZO - ochtend run
  De Procedure MOZSYSOCHTENDRUN, wordt alle dagen om 6:15 uur uitgevoerd. Uitgevoerde taken zijn onder andere:
  - verwerkt loggegevens (verplaatsen dagelijkse logdata naar verzameltabel)
  - verwijderen van verouderde tijdelijke data waarin diverse jobs uitgevoerd worden
  - versturen dagelijkse signaleringen (nieuwe documenten in voorkeurmappen, ongelezen documenten, etc)
  - verwerken agenderingen nieuws antwoord en webformulier
  - opnieuw berekenen doorlooptijden alle openstaande zaken en maken signaleringen
• MUT.OBJ.NAAM
  Verwerking achtergrondprocedure om namen gerelateerde objecten en zaken aan te passen aan wijzigingen.
• NWS.VERW.AGENDERING
  De voor vandaag geplande publicaties van Nieuwsitems worden geactiveerd
  (Is onderdeel van de ochtend run.)
• ONDH.TXT.INDX
  Deze job start om 00.30 en is voor het optimaliseren van de text indexen.
  Het is erg belangrijk voor de performance van deze indexen, dat deze plaats vindt buiten kantoortijd. Deze kost namelijk veel performance.
  (Is onderdeel van de avond run.)
  
• POSTINSTALLATIE
  Verslag van door ontwikkelaar geplaatst script in deze procedure welke 1 uur na de installatie van een release wordt uitgevoerd.
  
• PDF_CONVERSIE (MDCS)
  Zie ook koppelvlak voor binnenkomende pdf bestanden.
  (Loopt mee in de minutenrun.)
• PUBL.DIST.STUKKEN
  Plaatsen agenda/besluitenlijst in publicatiemap abonnementenmappen.
• RAADPLEEGVERZOEK
  Log van binnenkomend koppelverzoek voor raadplegen alle onderdelen van een zaak in XML formaat.
• RSSIGN
  Verwerking van reservering signaleringen. Verstuurt signaleringsmails indien aangegeven is dat men een herinneringsmail wil een dag van te voren.
  Is onderdeel van de avondrun.
• RTD - Real Time Data
• SCANVELOP
  De job wordt dagelijks automatisch gestart om 10:45 uur, 12:45 uur, 15:45 uur en 17:45 uur (scherm0901 checknieuw)
  Deze controleert de "scanvelop" directory op nieuwe bestanden. (Kan ook handmatig gestart worden door een postintake medewerker.)
  Onder de noemer scanvelop staan ook de POSTINTAKE scans deze job wordt dagelijks automatisch gestart om 09:35 uur, 10:35 uur en 15:35 uur ( scherm0900)
  Deze controleert de "scanpostintake" directory op nieuwe bestanden. (Kan ook handmatig gestart worden door een postintake medewerker.)
• SELECTIES
  Dit is de logging van zaak- of objectselecties indien hierin fouten optreden.
• TWSIGN
  Toewijzing signaleringen. Dit is de logging voor de signaleringen van toegewezen zaken mails die verstuurd worden.
• UPD.REDUNDANTE.KOL
  Logging voor het bijwerken van redundante in kolommen. Dit onstaat als dezelfde gegevens meer dan één keer in de database wordeen opnemen, dit wordt redundantie genoemd wat je dus wilt voorkomen.
• VULTAUT
  Wordt verwijderd vanaf versie 5.0, heeft geen werking meer

• WFR.VERW.AGENDERING
  De voor vandaag geplande publicaties van webformulieren worden geactiveerd
  Is onderdeel van de ochtend run.
• VERGEET.ME.NIET
  Logging voor het verwerken van de vergeetmenietjes. Hier vind je uitgebreide informatie welke vergeetmenietjes verwerkt worden en hoe lang dit duurde.
• WFR.VERW.AGENDERING
  De voor vandaag geplande publicaties van webformulieren worden geactiveerd.
  (Is onderdeel van de ochtend run.)
• WIJZIGDOC
  De job wordt dagelijks automatisch gestart om 9.30 uur en is voor mailtjes aangemaakt voor nieuw/gewijzigde documenten in voorkeurmappen.
• XSS-DETECT - wordt nu gelogd met als hoogste status signalering WA geel
  Logging van signalering van mogelijke Cross Site Scripting (XSS).
  XSS- progingen door 'hackers' om kwaadwillende scripts te injecteren in websites en applicaties,
• ZOEKEN
  Met deze job worden de zoek achtergrond procedures verwerkt , zoeksuggesties cash en zoekmutaties van namen en kenmerken in zaken, objecten, documenten, dossiers en mappen.
  Met dit onderdeel kan ook de Html opnieuw worden gegenereerd en de zoekomgeving opnieuw worden opgebouwd. (LET OP! Het opnieuw opbouwen van de zoekindex kost erg veel performance en kan het wel een aantal dagen duren voordat deze opnieuw is opgebouwd. Dus alleen in noodgevallen activeren in overleg met beheer Mozard medewerkers)
• ZOEKEN.DOCCONTENT - indexering van documenten in de volledige tekst
  Documenten met formaat 'Verwijzingsurl' (bv. webadres/zaak/formulier/Antwoord) en grootte 0 worden niet meegenomen in de indexatie van de zoekindex. 

*) Als er écht iets fout gaat in de code, wordt er bij LOGIN en DOC.NAAR.FS alsnog een fout gelogd. Er wordt alleen geen fouten meer gelogd waarbij er geen actie ondernomen hoeft te worden (zoals een mislukte inlog o.i.d.). Dit wordt als WA (geel) gelogd.

Mozard text indexen t.b.v. Zoeken

Alle text indexen worden bijgewerkt onder invloed van de minutenrun.

Door te klikken op een index wordt een scherm getoond waarin de status van de index wordt getoond.
Per onderstaand item kan de indexstatus bekeken worden: 
AANTEKENING_FULLTEXT; ANTWOORDZOEK_; DI_FNVB_TREFW_BO; DI_FNVB_TREFW_FO; GENERIEK_ZOEKEN_II; GENZK_HISTORIE; GENZK_SUGGESTIES; INTAKEZOEK; KENMERK_TEXTDOSSIER; MB_KENMERKTXT; MOZARD_GENZK_POLICY; MOZDOSMETA; MOZMEDEWERKER; MOZSUBDOSMETA; MOZSUBSUBDOSMETA; NAW_NAAM; POSTCODE_SUGGESTIES; ZOEKGM.

Via de knop/verwijzing in het rechter menu kunnen de volgende items geopend worden:

• met een klik op 'Toon Sync log’ wordt de log van het indexeren getoond;
• met een klik op‘Size report’ wordt de omvang van de opslag getoond per index onderdeel;
• met een klik op ‘Info report’ wordt de beschrijving en de index van de objecten getoond;
• met een klik op ‘Genereer creatiescipt’ Is het mogelijk het synchroniseren van de index met voorrang te forceren door ‘Pending queue’ te activeren. Het dringend advies is echter om niet niet te gebruiken en de minutenrun gewoon zijn werk te laten doen.

• LOG
  In deze zogenaamde APPLOG staan zoveel mogelijk de opgetreden fouten die kunnen ontstaan bij het uitvoeren van een procedure. Een log van een handeling door een gebruiker is te herkennen aan '[user]:' aan het begin van een logregel. Deze logging kan heel handig zijn als detailinformatie bij de uitwerking van een bevinding.
  We halen gewone mutaties zoveel mogelijk uit APP-log zodat er alleen fouten overblijven. Van de gewone mutaties maken we zoveel mogelijk extra opties in het statuspanel

• JOBLOG
  Logging van de uitgevoerde jobs die in de queue staan.

• VALID
  Hier wordt weergegeven welke packages, views of procedures invalid of disabled zijn.
  Als een package invalid is en na compileren er nog staat kan er mogelijk een probleem met de werking van Mozard zijn.

• SMSQUEUE
  Met een klik op SMSQUEUE wordt de log van de uitgaande SMS berichten getoond. Via ‘Wachtrij weergeven’ worden de (nog) niet verzonden SMS berichten getoond. Het kan ook zijn dat SMS-berichten niet worden verzondent omdat bijvoorbeeld het GSM-nummer ongeldig is, het aantal sms credits bij de sms provider op zijn of dat het certificaat door de provider is vervangen. Wat je in ook dit scherm ziet is telkens de inhoud van het sms-je met daarna de response van de sms-provider.
  Mogelijke meldingen zijn:
  01 [Het bericht is met succes verzonden]
  81 [Tekst error]
  89 [Verkeerde variabelen]
  93 [Incorrecte GSM-nummer(s)]
  95 [Het bericht is leeg (MSSG)]
  96 [Onvoldoende credits]
  97 [Username of Password verkeerd]
  98 [Geen toegang voor dit IP-adres]
  99 [Server niet bereikbaar]
  Met een klik op de X links van de berichtregel kan het veelal oude bericht verwijderd worden. Indien er geen gebruik gemaakt wordt van de functionaliteit SMS berichten kun je deze optie negeren.

• LAYOUTERR
  Hierin staan de opgetreden fouten in de layout. Dit kunnen plaatjes of pagina’s zijn die niet gevonden kunnen worden. Dit kan komen omdat een opgegeven plaatje niet gevonden kan worden of dat een verwijzing niet correct is.

• DIGIDLOG
  Hier vind je de logging van inloggen met DigiD terug. Bij eventuele fouten kun je hier een oorzaak terugvinden in de log.

• SHOWESES
  Hier worden alles sessies getoond zowel actieve als (kortgeleden inactieve). Hier kun je bijvoorbeeld zien waar de minutenrun mee bezig is en kun je ook zien als een sessie te lang bezig is en mogelijk vastgelopen (last call is vrij hoog dan). Aan de hand van het sessienummer kan de dba-er dan dit probleem verhelpen.

• SHOWLOP
  Hier wordt de voortgang van lang lopende acties getoond en hoe lang de actie mogelijk nog gaat duren.

• SHOWACL
  De Access Control List is eigenlijk firewall van de database. Hier wordt informatie getoond van alle ingestelde ACL’s (acces control list). Hierin staan de ingestelde url’s/ip-adressen waar de database toegang toe heeft inclusief via welke poort(en).
  Ook kan hier getest worden of een url bereikbaar is met een logging daarbij.

  Voor het toevoegen van een ACL zijn twee dingen nodig: de exacte naam zoals die benaderd wordt EN het poortnummer. Meestal is het handig om gewoon de url op te geven. Wanneer het een beveiligde verbinding is (HTTPS, SSL, TLS etc etc etc) dan is ook een certificaat nodig. Als je een certificaat meelevert moet je de VOLLEDIGE CHAIN aanleveren.
  Een certificaat wordt uitgeven door een instantie en ondertekend met het certificaat van die instantie: dat certificaat moet dus ook meegeleverd worden. Dat certificaat wordt ook weer uitgegeven door een hogere instantie en ondertekend met een certificaat enz enz enz. Zo ontstaat een keten. Die hele keten (chain) moet dus mee aangeleverd worden.

• De mailserver is het "ontkoppelpunt". Als mozard de mail succesvol kan aanbieden op de versturende mailserver/gateway/relayhost/firewall/hoe-men-het-ook-wil-noemen (= eigen interne mailserver van de gemeente) is daarmee de kous af.

Zolang mozard het mailtje niet kan aanbieden aan de relayhost blijft hij in mozard. Hij is dan te zien in het control paneel onder mail. Daar zie je alle mailtjes die nog niet verstuurd zijn. Als er berichten zijn met 10 verzendfouten kunnen deze gereset worden. Mailberichten die niet verstuurd zijn maar te oud om nog te versturen kunnen via de X aan het begin van de mailregel verwijderd worden.

Als de relayhost een mailtje niet kan bezorgen is het afhankelijk van hun eigen configuratie hoe dat afgehandeld wordt...

Conclusie/Kort samengevat:
Als het mailtje uit mozard is kunnen we deze niet meer volgen. Dat is het "ontkoppelpunt". De mail is dan door de mailserver van de klantorganisatie geaccepteerd. Vanaf daar is het de verantwoording van de eigen infra/configuratie. Zolang het mailtje niet door mozard succesvol verstuurd is(/kan worden), blijft hij in mozard en gaat hij zeker niet verloren. Echter na 10 pogingen worden de verzendpogingen gestaakt.

E-Mail zonder referentiecode / Zaak niet te bepalen
Wanneer de klant van een zaak op de mail terug reageert dient hij de referentie, welke mee gestuurd wordt, onder aan de mail te laten staan. Maar het kan voorkomen dat de klant deze heeft verwijderd, of dat hij gebruikt maakt van een automatisch antwoord.

De binnenkomende mail zonder referentie kan veelal toch in de juiste zaak geplaatst kunnen worden op basis van het onderwerp of het e-mailadres van de afzender. Hierbij worden de volgende controle stappen uitgevoerd:

1. uit het onderwerp van de binnenkomende e-mail wordt het eerst voorkomende nummer (vanaf het eerste cijfer tot het eerste niet-cijfer) geselecteerd en dat wordt beschouwd als het zaak nummer. Als het zaaknummer voor komt dan wordt het e-mailbericht in het bij EML_DOSSIER vermelde zaakdossier geplaatst,
2. komen de eerste dertig posities van een recent (laatste vier uur) vanuit Mozard verstuurd e-mailbericht voor in het onderwerp van de binnenkomende e-mail? Zo ja, dan wordt het e-mailbericht in het bij EML_DOSSIER vermelde zaakdossier geplaatst,
3. komt de domeinnaam van de afzender van de binnenkomende e-mail overeen met die van een geadresseerde van het verstuurde bericht? Zo ja, dan wordt het e-mailbericht in het bij EML_DOSSIER vermelde zaakdossier geplaatst,
4. komt als het e-mailadres bij precies één lopende zaak voor? Zo ja, dan wordt het e-mailbericht in het bij EML_DOSSIER vermelde zaakdossier geplaatst.

Komt het e-mailadres dus bij meerdere lopende zaken voor, dan plaatsen we het bericht dus niet in één van de betreffende zaakdossiers. Het bericht wordt in dat geval in de map ‘Niet te verwerken binnenkomende e-mailberichten’ geplaatst voor handmatige verdeling door de functioneel beheerder.