Oppsett

Generelt

Her skal vi forsøke å beskrive litt de spesialiteter som gjelder for AV Dialog. En viktig og litt spesielt forskjell i denne løsning kontra øvrige Adaptive installasjoner/moduler er at vi her benytter instanceid for å skille de ulike kundene. Dette er en såkalt multitennant løsning hvor samme site benyttes for flere ulike kunder med sine oppsett og kodeverk. Bruk av instanceid gir noen muligheter, men også ting en må passe på vi skal forsøke å beskrive nedenfor. Instanceid for en kunde vil man se i admin og ellers i tabellen tbl_instance.

Koder

Alle koder som benyttes i løsning ligger i tabellen tbl_code. Koder som benyttes default er de som er definert for instanceid -1. Man kan bytte ut alle eller enkeltvis disse koder ved å legge til tilsvarende, men med egen instanceid. På denne måte trenger man ikke bytte ut samtlige koder, men kun de hvor man har behov for å endre. Det kan likevel kanskje være greit å legge inn samtlige koder for en for en kunde. Gir enklere oversikt. Kodetabellen inneholder referanse til tabell og felt i tabell. Dessuten vil koder for egenskapen kode (detail) ha referanse til tema (topic). Også viktig i tabellen er egenskapen ispublic som styrer hvorvidt dette er en kode som også skal vises i publikumsdelen av Dialog. Egenskapen tag er så den spennende. Denne benyttes for å automatisere selve løsningen. Her definerer man ved hjelp av json ulike funksjonalitet som ønskes. Tips angående JSON – benytt f.eks http://jsoneditoronline.org/ for å definere og kontrollere de uttrykk du legger inn.

Arv av koder

Dersom man har laget et kodeoppsett for en kunde man også ønsker å benytte for en annen, så kan man arve disse. Tabellen tbl_code_join gir en mulighet for dette. En god bruk av dette er f.eks tre kommuner som benytter et felles renovasjonsselskap. Man ønsker mulighet til å registrere renovasjonsmeldinger også i kommunens løsninger. Her kan man så sette opp koder for renovasjonsselskapet og legge inn en link i nevnte tabell slik at de andre kommunen arver disse koden. Benytter man i tilegg en post-funksjon slik at instanceid sette for renovasjonsselskapet ved lagring vil man også flytte ansvar for å håndtere renovasjonshenvendelsen til renovasjonsselskapet. Renovasjonsmeldinger som har kommet inn for en kommune kan likevel vises i publikumsdelen om man ønsker det.

Funksjoner og bruk av tag felt

Funksjoner som legges inn i tag feltet er av to typer:

• Pre-funksjoner som fungerer under innregistrering av en melding
• Post-funksjoner som utføres etter at bruker lagrer sine endringer

Post-funksjoner innledes alltid med en hashtag # eller en alfakrøll @ for å indikere dette. Man kan lage en pre- og en post-funksjon som påvirker samme felt, f.eks ansvarlig, slik at feltet får en verdi i det man registrere og en ny etter at man har trykket lagre. Kanskje en situasjon man bør unngå fordi den forvirrer. Nedenfor skal vi gå gjennom de ulike mulighetene.

Pre-funksjoner

Hjelpetekst/info ved registrering

Fører til at det kommer opp en melding til bruker når kode med denne tag velges. Benyttes for å orientere om hva som vil skje eller om det er andre steder man skal henvende seg for denne type avvik. Fungerer bår i publikumsdelen og behandlingsdelen av løsningen. Bruk av guidence kan legges til emne (topic), detaljkode (detail) og behandling (treatment)

[
  {
    "key": "guidance",
    "value": "Husk å sett dato for utbetra"
  }
]

Logdate

Alle endringer i løsning logges med aktuelt tidspunkt. Det kan av og til være behov for å overstyre denne – f.eks for en renovatør som ønsker å fortelle hvilket tidspunkt en renovasjonsdunk ble byttet. Bruk av denne innebærer at man setter logdate som nøkkel og så legger inn tekst som skal komme opp i logg som value. I eksemplet nedenfor vil «Utbetra» komme opp som tekst på det tidspunkt man har angitt. Logdate kan legges til emne (topic), detaljkode (detail) og behandling (treatment).

[
  {
    "key": "logdate",
    "value": "Utbetra"
  }
]

Tredje part bruker

Dette er en mulighet for gi en tredjeparts bruker en utvidet tilgang til noe funksjonalitet i løsning. Vanligvis skiller vi bare på de muligheter publikum får gjennom publikumsløsning hvor enkelte koder kan være interne (angitt som ispublic=false i kodetabellen). I behandlingsdelen vil derimot alle brukere registrert med rolle rediger ha tilgang til alt. Det kan være behov for å regulere tilgang for ulike brukere av behandlingsdelen. Et eksempel kan være renovatør som bare skal ha tilgang til å endre behandlingstype og legge kommentarer til denne. Dette kan så styres ved at man legger inn alloweddomain i tilknytning til department. For å forklare dette. Ansvarlig avdeling (department) kan settes av løsning automatisk eller av bruker. Når så en bruker logger seg inn med en epostadresse som inneholder f.eks domenet «renonorden.no», så vil denne bruker få tilgang til å endre meldinger hvor renonorden er satt som ansvarlig. Muligheten man har er å endre behandlingskode, legge til en kommentar og kanskje sette en dato gitt ved hjelp av logdate slik beskrevet over. Alloweddomain kan bare legges til ansvarlig avdeling (department).

[
  {
    "key": "alloweddomain",
    "value": "renonorden.no"
  }
]

Ekstrafelt («add» og «addinternal» )

Det er definert 5 ekstrafelt man kan sette opp for spesielle meldinger. Hvis man f.eks ønsker spesielle opplysninger slik som «Når satte du fram søppeldunken» for en type melding så kan dette legges inn eller også ønsker å skjule uaktuelle egenskaper. Man benytter tagen add og hide for dette. Når man legger til felt må man sette navn på ekstrakolonne og navnet denne skal få. Ekstrakolonne navngis extra1, extra2 osv til 5. Merk at ekstrafelt er rene tekstfelt uten kontroll av type eller verdi. «Add» leger til et felt som også vises i publikumsløsning. «Addinternal» vil kun vises i behandlingsløsning.

Ekstrafelt kan legges til på såvel topic som detail. Merk at legger man dette til på topic så vil ekstrafeltene beholdes når man setter detail. Dette kan man derimot overstyre ved å legge til en definisjon også på detail. Ønsker man å fjerne ekstrafelt på en detail legger man inn en blank som vist nedenfor.

[
  {
    "key": "add",
    "value": {}
  }
]

Skjule felt

I kombinasjon med nye ekstrafelt kan det være aktuelt å skjule noen av de standardfelt som finnes. Ved hjelp av kommandoen ‘hide’ kan man skjule disse. Denne funksjonen kan bare benyttes på topic. Hver gang man bytter topic vil standardfelt initielt vises. Følgende felt kan skjules: Navn (persname), adresse (persadress), telefon (persphone), epost (persemail), meld type (feedbacktype), meldt dato (feedbackdate), intern melding (internalmsg), avdeling (department) eller ansvarlig (responsible).

NB! Funksjonen ‘hide’ BARE kan benyttes for topic. 

[
  {
    "key": "hide",
    "value": {
      "fields": [
        {
          "value": "persphone"
        },
        {
          "value": "persname"
        }
      ]
    }
  }
]

Sette øvrige verdier

Når man registrerer en ny melding så kan det opprettes trigger på emne (topic), detaljkode (detail) eller behandling (treatment) for å sette forslag til verdi på samtlige nedtrekksmenyer. Man må passe på å sette en lovlig verdi (dvs en som allerede er definert). Verdi kan således settes på kode (detail), behandling (treatment), avdeling (department) eller ansvarlig (responsible). Nedenfor ser man et eksempel på hva som kan legges inn på f.eks behandling (treatment).

[
  {
    "key": "status",
    "value": "Utbedret"
  },
  {
    "key": "department",
    "value": "NGIR"
  }
]

Kontrollfunksjoner (controlfunctions)

Dette er en mulighet til å sjekke om man har pekt på et belysningspunkt, riktig veg osv før melding blir registreret. Vi oppretter funksjoner i basen som tar i mot en koordinet som benyttes som grunnlag for kontroll. En lager en funksjon pr kontroll som skal utføres. Funksjon returnerer en melding som vises i klienten slik at man kan korrigere melding. Merk at du her kan legge inn flere kontroller adskilt med semikolon. Rekkefølgen på kontrollene kan dermed også gis. Funksjon definert i PostGres må være på formen av_data_46.av_check_gatelys(text, integer) og dersom denne returnerer noe annet enn tom streng oppfattes dette som en advarsel som skal meldes.

[
  {
    "key": "controlfunctions",
    "value": "av_check_gatelys"
  }
]

Post-funksjoner

I det bruker trykker lagre sendes melding over til server. Her vil nye regler kunne påvirke hvordan melding til slutt lagres. Server kan overstyre noen av de valg man har foretatt på klienten dersom dette er lagt inn i konfigurasjonen. Som bruker har du kanskje valgt at ansvarlig skal være «Drift avløp», men server kan overstyre dette til å være «Drift vann» osv. Vi skal se nærmere på noen av de muligheter som ligger inne. Aller først – alle postfunksjoner er innledet med # eller @ for å synliggjøre dette på en bedre måte. Dessuten – postfunksjoner kan bare knyttes til tema (topic) eller kode (detail).

Gi melding (#inform)

Denne benyttes for å sende melding til noen. For enkelte meldinger er det nyttig å gi en tilleggsmelding til ansvarlig ved hjelp av en epost eller SMS for å varsle. Email, mobile eller begge fylles ut etter ønske. Message er tekst man ønsker å sende.

Feedback er tilbakemelding til publikum om hva som er foretatt. Hvis noen rapporterer hull i veg vil andre kanskje være interessert i hva som foretas for en slik henvendelse. En bør derfor tenke nøye gjennom hva og om man ønskeren slik tilbakemelding. I tilfeller hvor kommunen ikke har et ansvar for det som meldes, men kanskje automatisk videresender e mail til rette instans så vil en tilbakemelding alal «Melding om forhold er videresendt Statens Vegvesen» være på sin plass.

[
  {
    "key": "#inform",
    "value": {
      "email": "Ole.Olsen@ kommune.no",
      "mobile": "",
      "message": "Melding om avvik avløp mottatt",
      "feedback": ""
    }
  }
]

Sett andre egenskaper (@xxxx)

Egenskaper for tema (topic), kode (detail), behandlig (treatment), avdeling (department), ansvarlig (responsible) og intern melding (internalmsg) kan settes. I tillegg kan instanse id settes (instanceid). Dette innebærer at man kan flytte en melding til en annen kommune eller annen bruker av Adaptive Dialog. Et eksempel her er meldinger på renovasjon som kanskje håndteres av et interkommunalt renovasjonsselskap som også benytter Adaptive Dialog for sine henvendelser. Husk å sette @ før navn på egenskap som vist nedenfor. [ { «key»: «@instanceid», «value»: «5» }, { «key»: «@department», «value»: «Retura» } ]

Hent egenskap fra eget punktlayer (#snapdigi)

Dette er en mulighet for å hente informasjon fra et digitheme i Dialog. Det kan være navnet på en miljøstasjon, nummer på et gatelys, id for en kum osv. Funksjonen snapper til nærmeste punkt innenfor 10 meter. Digitheme må vises som et layer i løsning, publisert som et WMS lag. Bør derfor kombineres med «Vis aktuelle layer» beskrevet nedenfor.

[
  {
    "key": "#snapdigi",
    "value": {
      "tablename": "table_kummer",
      "valuefield": "type",
      "feedbackfield": "",
      "query": [
        {
          "value": "vann",
          "email": "postvann@min.kommune.no",
          "mobile": "",
          "message": "Det er kommet en melding om feil på en vannkum!",
          "feedback": "",
          "set_responsible": "Drift vann",
          "set_treatment": ""
        },
        {
          "value": "avlop",
          "email": "postavlop@min.kommune.no",
          "mobile": "",
          "message": "Det er kommet en melding om feil på en aløpskum!",
          "feedback": "",
          "set_responsible": "Drift avløp",
          "set_treatment": ""
        }
      ]
    }
  }
]

Følgende egenskaper må angis:

• Tablename – er navnet på tabell i database
• Valuefield – er felt man henter verdi fra
• Feedbackfield – er felt man kan hente en tekst for tilbakemelding til melder Man setter så opp en query for hva slags håndtering man ønsker utfra oppslaget. Query kan bestå av flere, men benytter man verdi «?» så vil denne gjelde alle verdier man ikke finner oppslag på. I en query kan man således sette opp litt som for #inform:
• Email – for hvem epost skal sendes til
• Mobile – hvis man ønsker automatisk sendt SMS
• Message – som er melding på det man sender
• Feedback – som er tilbakemelding til melder dersom feedbackfield ikke er utfyllt.
• Set_treatment – kan benyttes for å sette behandling
• Set_responsible – kan benyttes for å sette ansvarlig

Koble til Norkart FDV

Det er mulig å sende utvalgte hendelser til Norkart sin FDV løsning ved hjelp av dette oppsett.

 [
  {
    "key": "#norkart",
    "value": {
      "tablename": "vedlikeholdomraader",
      "valuefield": "gatelys",
      "digitype": "contains",
      "url": "https://varegister-test.azurewebsites.net",
      "kundeid": "1234567890",
      "username": "USERNAME",
      "password": "PASSWORD",
      "tag": "{valuefield}"
    }
  }
]

• Tablename – spatial tabell man skal gjøre oppslag mot. Settes tom hvis ikke oppslag ikke benyttes
• Valuefield – felt i tabell over man henter verdi fra. Hvis tablename ikke er oppgitt benyttes denne verdi ikke.
• Digitype – type oppslag som kan være «snap» eller «contains». Hvis tablename ikke er oppgitt benyttes denne verdi ikke.
• Url – mot tjenesten man kommuniserer
• Kundeid – oppgis av Norkart
• Username – oppgis av Norkart
• Password – oppgis av Norkart
• Tag – oppgis av Norkart. Hvis man benytter oppslag mot tabell og setter tag lik «#» + valuefield, så vil verdi fra oppslag sendes over som tag.

Hent egenskap fra eget flate layer (#containsdigi)

Denne funksjonen oppfører seg som for #snapdigi bortsett fra at denne forholder seg til en flate i stedet for punkt. Sjekker om melding er plassert innenfor en flate.

Finne vegeier

En egen funksjon kan benyttes for å sjekke hvem som er eier av vegen meldingspunkt er plassert i eller like ved. Vi benytter Statens Vegvesens NVDB API for dette. Nedenfor ser man hvordan dette fungerer.

[
  {
    "key": "guidance",
    "value": "Pek i kartet for plassering av hull i veg slik at vi kan avgjøre ansvar!"
  },
  {
    "key": "#nvdb",
    "value": {
      "type": "vegreferanse",
      "field": "vegKategori",
      "query": [
        {
          "value": "E",
          "email": "post@vegvesen.no",
          "mobile": "",
          "message": "Melding om hull i veg!",
          "feedback": "Melding videresendt Statens vegvesen",
          "set_responsible": "Statens vegvesen",
          "set_treatment": "2:Ikke vårt ansvar - videresendt til ansvarlig"
        },
        {
          "value": "K",
          "email": "post@min.kommune.no",
          "mobile": "",
          "message": "Melding om hull i veg!",
          "feedback": "Melding mottatt og vil håndteres av kommunen",
          "set_responsible": "Drift veg",
          "set_treatment": ""
        },
        { ..osv.. }
      ]
    }
  }
]

Egne funksjoner (#callfunction)

En siste mulighet til å manipulere data når disse lagres er å benytte funksjoner som legges i databasen. Her kan man lage funksjoner som gjør ulike ting. Merk at selve meldingen allerede er lagret i basen med sine egenskaper. Man kan derfor ta utgangspunkt i disse for eventuelle justeringer.

[
  {
    "key": "#callfunction",
    "value": "av_dialog.av_get_ngir_route"
  }
]

Selve funksjonen opprettes i databasen med meldingsident (point_id) som eneste argument f.eks slik:

CREATE OR REPLACE FUNCTION av_dialog.av_get_ngir_route(point_id integer)
  RETURNS boolean AS
$BODY$
BEGIN
	..kode..
END;

Vise aktuelle layer (kun publikumsdel)

Publikumsdelen har noen funksjoner som kan benyttes fra konfigurasjon for å vise aktuelle layer tilhørende en type melding. Man må ha sette opp en WMS tjeneste for aktuelt tema og når dette er gjort vil dette vises når tema (topic) eller kode (detail) velges.

[
  {
    "key": "wms_uri",
    "value": "https://demomaps.adialog.no/wms.ashx?"
  },
  {
    "key": "wms_layer",
    "value": "layer_digi_2"
  }
]

Legg inn wms_uri til selve tjenesten og angi tilhørende wms_layer.

Annen funksjonalitet

Default verdier

Et par andre ting man skal være klar over er kontroller og forutsetninger som alltid ligger inne i løsning.

1. Hent default status – Dersom status i forhold til behandling ikke er oppgitt vil Dialog automatisk plukke den første og beste. Dette kan bli riktig, men avhengig av hvordan koder er lagt inn så kan dette også bli feil (avhenger av rekkefølge). Anbefaling er å sette status for ulike behandlingskoder.
2. Hente default ansvarlig – Samme gjelder her og forsøke å sette disse riktig. Merk at de to nevnte kan settes for tema (topic) eller kode (detail). Det smarteste er å sette dette for tema slik at man slipper å legge inn konfigurasjon for hver eneste kode.

Kontroller

Når data lagres er det et par kontroller man kan være klar over.

1. Kontroll på utført. Dersom status er satt til «behandlet» eller «utført» og melder har bedt om tilbakemelding så sjekkes det om dette faktisk gjøres. Dvs om man har lagt inn en kommentar og huket av for «Meld tilbake». Hvis ikke får man en feilmelding.
2. Kontroll på logget dato – Benytter man felt for å logge spesielle aktiviteter med egen ato så sjekkes det om feltet er utfylt.

Oppslag telefon

Hver gang man fyller ut et telefonnummer så foretas det et oppslag mot tjenester levert av Link Mobility for å finne eiers navn, adresse og adressens koordinater. De fleste telefonnummer fungerer på dette, men det finnes unntak. En kan sjekke på www.gulesider.no som benytter samme tjeneste.

Tekster

En rekke tekster kan endres i løsning. Tabellen tbl_lang inneholder tekster som benyttes i løsning. Tekster til instance -1 er de som benyttes default. Man kan imidlertid legge inn egne tekster ved å legge til en tekstid, men med riktig instanceid. Et eksempel er mail_footer som vil være «underskriften» på mail som løsning sender ut. Denne bør legges inn med f.eks teksten «Vennlig hilsen Meland kommune» osv..

Arv av tekster

På samme måte som koder kan arves kan man også arve tekster. Dette kan være nyttig hvis man har opprettet en egen nynorsk variant av teksoppsettet. Opprett link til riktig instance og legg denne inn i tbl_lang_link. Pass likevel på å legge til de tekster som inkluderer navn på kommune osv.

Filter

Figur 1 Filter for bruk i løsning

I Dialog kan bruker benytte filter som er satt opp i forbindelse med oppsett av løsning. Disse filter bygges opp etter ExtJS prinsippet med JSON som vist nedenfor:

[
  {
    "name": "status",
    "comparisonOperator": "=",
    "value": "Ubehandlet",
    "netType": "string",
    "logicalOperator": "AND"
  }
]

Prinsippet er i utgangspunktet enkelt og funksjonen vi ser her vil vise alle meldinger hvor status er satt til Ubehandlet. Det vises til dokumentasjon for ExtJS for nærmere bruk av dette. Filter legges inn i tabellen tbl_filter med en forklarende tekste og selvsagt instanceid.

Funksjoner

Figur 3 Funksjoner for superbruker

Super bruker av løsning vil ha tilgang til en eget verktøy for å legge til nye brukere i tillegg til noen spesialfunksjoner. Disse spesialfunksjoner må defineres i database, men man kaller disse gjennom en definisjon som legges inn i tabellen tbl_function. Uttrykket er svært enkelt. Legges inn med en forklarende tekst og instanceid i tabellen. Selve uttrykket kaller på en funksjon i databasen. Instanceid settes automatisk inn som første parameter.

[
  {
    "functioncall": "av_set_archived(instanceid,2)"
  }
]

Sette i en portalløsning

Her et eksempel på hvordan en iFrame kan settes inn på en web side:

<iframe src="https://m.adialog.no/dialog/molde" height="600" width="100%"></iframe>
</code >

Og her et ekesempel på hvordan dette da kan se ut: