Introduksjon:
Du finner rapporteringsløsningen på følgende url: rapport.cubit.no. Merk at du må være innlogget i Cubit Brann for å ha tilgang til rapporteringsløsningen.
Rapporteringsløsningen er en sandkasse hvor du kan bygge akkurat de rapportene du ønsker. Denne dokumentasjonen inneholder informasjon om hvordan du bygger rapporter, hva de enkelte feltene inneholder, råd og tips til hvordan du utnytter funksjonaliteten best mulig. Appendiks inneholder oversikt over felter og hvilken data de inneholder.
Det vil også komme ut en mer generell brukerdokumentasjon i kunnskapsdatabasen. Følg med der.
Grunnlagsdata:
Rapporteringsløsningen inneholder to ulike datagrunnlag.
Buildings (bygninger) og Audits (tilsyn). Disse to spørringene vil gi deg forskjellige svar, forskjellige felter og et forskjellig datagrunnlag for videre arbeid.
Bygninger - dette datagrunnlaget inneholder alle ildsteder, alle matrikkelenheter, alle røykløp osv. Dette er i hovedsak til fullstendige anleggsregister
Tilsyn - dette grunnlaget inneholder alle ildsteder, alle matrikkelenheter, alle røykløp osv med en relasjon til en aktivitet, søknad eller tilsyn / feiing.
Det er ekstremt viktig å forstå forskjellen mellom disse to datagrunnlagene.
Rapporter og rapportgrupper:
Den videre strukturen i rapporteringsløsningen består i rapporter og rapportgrupper. Rapporter er basert på et datagrunnlag (bygninger / tilsyn) og de feltene som datagrunnlaget har. En rapportgruppe er en samling av rapporter. I figuren under vil du se hvordan dette ser ut. Her har vi Fellesrapporter som er en rapportgruppe. Denne består så av flere rapporter. I tilfellet for Fellesrapporter er dette Alle avvik, Røykløp osv. En rapport kan du dra mellom rapporteringsgruppene. 
Oppsett:
Rapporteringsløsningen i Cubit gir deg stor fleksibilitet. Dermed er det viktig å være nøye på hvordan dashbordet og rapporter arbeides med og “produksjonsettes”. Når du starter anbefaler vi deg at du først setter opp noen rapportgrupper. Vi anbefaler alltid at du har en rapportgruppe som du kaller “Test” og en som du kaller “ Produksjon” eller lignende. Dette gjøres slik at brukerene i ditt brannvesen enkelt kan se hvilke rapporter som er ferdige og kvalitetssikret og hvilke rapporter som ikke er ferdige eller kvalitetssikret.
Når brukerene dine er blitt vant med denne prosessen kan du legge til flere rapportgrupper som inneholder ferdige og kvalitetssikret data. Da anbefaler vi at du legger den videre strukturen opp etter datagrunnlag.
Eksempel: 
Bygging av rapporter - nybegynner
Det første og viktigste valget du tar når du skal bygge en rapport er datagrunnlaget. Du må dermed først forstå hva data du er ute etter og deretter velge det datagrunnlaget som gir deg dette. Gi også rapporten en tittel og legg alltid en rapport du jobber på i “test” rapportgruppe. Du kan endre navn på rapporten og rapportgruppen når du har bygd den helt ferdig og verifisert at dette er data du faktisk er ute etter. Når du har opprettet rapporten og lagt den i en rapportgruppe vil du bli tatt til en tom side. Trykk her på konfigurer for å bygge rapporten.
Du kan nå begynne å hente inn data. Trykk, ny kolonne og velg akkurat det feltet du ønsker. Gi feltet et navn og lagre kolonne.
Når du har valgt alle kolonnene du ønsker å ha inn i denne rapporten, så kan du velge filtre. Filterene vil pivoterte kolonnene dine basert på det du velger i filtrene.
Å lage et filter er rimelig likt det å legge til en ny kolonne, men med noen ekstra funksjoner.
Du må legge til en operatør. Operatøren sier noe om hvordan data skal presenteres som filter. I eksempelet over har jeg valgt et datofelt og jeg må velge operatør Date.
I det neste eksempelet har jeg valgt et nummer. Da får jeg flere alternativer. Jeg kan, i filteret, legge det som en tekst-input, som et flervalg eller som et enkelt valg i en dropdown-liste. På noen felter kan du velge mindre enn, større enn, lik eller inneholder. Videre kan du så inkludere, ekskludere data . Dette ser du i eksempelet under. Det kan være at du ikke ønsker å ha med inaktive røykløp. Da kan du ekskludere disse når du lager filteret.
Vi anbefaler imidlertid at du starter uten restriksjoner slik at du kan bli kjent med hovedfunksjonaliteten i rapporteringsløsningen først.
Du kan nå lagre og kjøre rapporten for første gang.
Det kan være lurt å lage rapporten generell, altså at den kan dekke flere brukstilfeller. Den enkelte bruker kan da bruke filtrene for å kjøre den rapporten de ønsker. Dette kan også lastes ned til Excel for videre prosessering.
Bygging av rapporter - avansert:
I en kolonne kan du toggle på “Tilpasset data” .
Dette gir deg muligheter til å skrive en del sql spørringer. Per nå er sql’ene som kan skrives begrenset til aggregeringfunksjoner. Dette er funksjoner som teller, summerer eller velger spesifikke felt eller kolonner. Du kan ikke ha en SELECT og WHERE da vi ikke støtter sub- spørringer mot datasettene men du kan ha en Count og WHERE
Følgende aggregeringsfunksjoner støttes:
AVG() - returnerer gjennomsnittlig verdi
COUNT() - antall rader - velg COUNT (DISTINCT dersom du skal telle unike rader.
FIRST() - første verdi
LAST() - siste verdi
MAX() - største verdi
MIN() - minste verdi
SUM() - sum
Selv om du ikke kan kjøre sub-spørringer kan du lage avanserte spørringer. Disse spørringene kan igjen kobles mot filtreringer som kommunenavn, gateadresse eller annen geografisk eller anleggsinformasjon.
Appendiks 1b:Datagrunnlag - bygning
Rapporteringsløsningen inneholder mange felt. Feltene er delt inn i logiske grupper. For bygninger er dette følgende grupper:
Building - dette er bygninger fra matrikkelen
Housing Unit - dette er boenheter fra matrikkelen
Matrikkel Unit - dette inneholder informasjon om matrikkelenheter
Chimney - informasjon om skorstein
Fireplace - informasjon om ildstedet
Alle felter har en kobling mot en av gruppene. Over kan du se hvordan feltnavnet “Attributt på bygning” ligger i gruppen” Building”. Alle felt har en prefix som henviser til gruppen feltet ligger i. Alle felt er oversatt slik at du enkelt kan forstå hva feltet inneholder. Felt som er merket med ID. Disse felt som inneholder en unik nøkkel. Disse feltene er dermed veldig nyttige for aggregeringsfunksjoner som SUM(), COUNT() eller lignende
Appendiks 1b:Datagrunnlag - tilsyn
Rapporteringsløsningen inneholder mange felt. Feltene er delt inn i logiske grupper. For tilsyn er dette samme gruppene som over men med prefixen “Audit”
Building - dette er bygninger fra matrikkelen med kobling til et tilsyn / aktivitet
Housing Unit - dette er boenheter fra matrikkelen med kobling til et tilsyn / aktivitet
Matrikkel Unit - dette inneholder informasjon om matrikkelenheter med kobling til et tilsyn / aktivitet
Chimney - informasjon om skorstein med kobling til et tilsyn / aktivitet
Fireplace - informasjon om ildstedet med kobling til et tilsyn / aktivitet
I tillegg vil du finne en del felter nederst i datagrunnlaget tilsyn som ikke har en prefix. Dette er datofelt.
Over vil du se prefix og feltnavn. Forklaring på feltet ligger på norsk helt i starten.
Appendiks 2:Teknisk dokumentasjon - for den interesserte (engelsk)
Overview
The Cubit Reporting Service is a robust backend platform aimed at enabling tenants who use the Cubit auditing system to generate highly customized reports. Importantly, this service does not generate or maintain its own database but relies on pre-existing SQL views, known as "base queries," that are prepared by the report-relay system.
###Technologies
MS SQL Prod Database Hosted on Azure
MS SQL Dev Database Hosted on Azure
API dev and prod slots hosted on Azure
.NET 7.0
Entity Framework
Deployment: GitHub Actions ###Setup
Visual Studio for debugging
Structure
Understanding Base Queries
A base query is fundamentally a SQL query that acts as the initial dataset or the "starting point" for tenants to construct their customized report templates. A base query is a dynamic query, serving to load data from predefined SQL views. These views perform LEFT JOIN operations on related tables, creating a comprehensive dataset that includes all possible permutations of related data.
The parameters for each base query are stored in the ReportBaseQuery table. This table dictates the fields that are accessible through the base query, specifies which types of tenants can access it, and defines the ViewName that the base query will pull its data from. Here's how it works in practice. To generate a customized report, the following query structure is utilized:
SELECT COUNT (DISTINCT [Audit Chimney number]) "Antall", "Audit Chimney Type", "Audit Chimney IsInUse" FROM
( BASE QUERY HERE )
x GROUP BY "Audit Chimney number", "Audit Chimney Type", "Audit Chimney IsInUse"
In this example, you can observe the custom operation COUNT() which is built upon the foundational dataset provided by the base query. A typical base query might look something like this:
(SELECT [Id], [AdditionalType], [CaseNumber], ... FROM [AuditFireRelayBaseQuery@ExampleTenantName] WHERE 1=1 )
This base query exposes a multitude of fields, which are defined in the ReportBaseQuery table. The actual SQL view from which the base query fetches its data is a concatenation of viewName and @tenantName. So, for instance, the base query draws from a view named AuditFireRelayBaseQuery@ExampleTenantName.
The flexibility offered by this approach allows tenants to craft highly specific and tailored reports. Whether they want to query for "all inactive chimneys" or apply other types of filtering and aggregations, the wide range of data permutations made available through the base query accommodates such customizations.
It should be noted that these SQL views are generated by another service, report-relay and must already exist for the base query to operate correctly. This service merely expects the views to be in place with all the necessary data, but is not responsible for creating or managing these views.
Handling Fields Changes in Base Queries
If a new field is added or changed to a base query externally, update the Fields column in the ReportBaseQuery table to include the new field. This ensures that the new field can be leveraged in the reports that build upon that base query.