Kravspesifikasjon Mamut Webforms 1 av 52 -...

Kravspesifikasjon Mamut Webforms 1 av 52

KRAVSPESIFIKASJON

HOVEDPROSJEKTETS TITTEL

System for generering av webskjemaer for Mamut ASA

DATO

24.05.2011

ANTALL SIDER

53

PROSJEKTDELTAKERE

Kjetil Hårtveit, s155501 INTERN VEILEDER

Alfred Bratterud

OPPDRAGSGIVER

Mamut ASA KONTAKTPERSON

Espen Johannessen

SAMMENDRAG

Systemet som er utviklet brukes til å generere webskjemaer. Hensikten med systemet er å

øke datakvalitet ved å fjerne manuelle rutiner, redusere svinn av leads og øke salg gjennom

bedre oppfølging av leads. Systemet er utviklet med Microsoft teknologier C#/ASP.NET med

MSSQL og Windows Service.

3 STIKKORD

Mamut Webforms

Webskjemagenerering

.NET

Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo

Besøksadresse: Holbergs plass, Oslo

PROSJEKT NR.

11-34

TILGJENGELIGHET

Åpen

Telefon: 22 45 32 00

Telefaks: 22 45 32 05


Revisjon 16 20. mai 2011

Innholdsfortegnelse 1. Introduksjon ........................................................................................................................... 3

1.1 Hvem bør lese dokumentet ........................................................................................... 3

1.2 Dokumentets rolle i prosjektet ..................................................................................... 3

1.3 Ordforklaring ................................................................................................................ 3

2. Om systemet ........................................................................................................................... 4

2.1 Om bedriften ................................................................................................................ 4

2.2 Opprinnelig situasjon vs. ønsket situasjon ................................................................... 4

2.3 Mål med systemet ......................................................................................................... 6

3. Roller ...................................................................................................................................... 6

4. Språk ....................................................................................................................................... 6

4.1 Språkliste ...................................................................................................................... 6

5. Database ................................................................................................................................. 7

6. Innholdsstruktur ................................................................................................................... 14

7. Grensesnitt ............................................................................................................................ 16

7.1 Hovedmeny ................................................................................................................ 16

7.2 Seksjon: User .............................................................................................................. 17

7.3 Seksjon: Forms ........................................................................................................... 19

7.4 Seksjon: Categories .................................................................................................... 27

7.5 Seksjon: Analysis ....................................................................................................... 30

7.6 Seksjon: Export .......................................................................................................... 34

7.7 Seksjon: Logging ........................................................................................................ 38

8. Funksjonalitet og spesifisering ............................................................................................. 41

8.1 Generering av skjemakode ......................................................................................... 41

8.2 Prosessering av skjemadata ........................................................................................ 42

8.3 Generering av CSV fil ved eksportering .................................................................... 43

8.4 Manuell eksport .......................................................................................................... 44

8.5 Automatisk eksport .................................................................................................... 44

8.6 Loggføring .................................................................................................................. 47

8.7 Feilbehandling ............................................................................................................ 48

Ressurshåndtering .................................................................................................................... 49

8.8 Ressursoversikt ........................................................................................................... 49

9. Forbindelse mellom system og webskjema .......................................................................... 50

9.1 Rollene ....................................................................................................................... 50

9.2 Data fra skjema til server ........................................................................................... 50

10. Tilgangsbegrensning .......................................................................................................... 52

11. Design ................................................................................................................................. 52

11.1 Prinsipper ................................................................................................................. 52

11.2 Farger ....................................................................................................................... 52

12. Programmeringsmønster (ASP.NET MVC2) .................................................................... 52

13. Kodekonvensjon ................................................................................................................. 52


1. Introduksjon

1.1 Hvem bør lese dokumentet

Dette dokumentet er hovedsakelig beregnet for utviklere som trenger å sette seg inn i systemet

av vedlikeholds-, videreutvikling eller andre grunner. Visse detaljer er også nyttig for

markedsføreransvarlig å sette seg inn i ettersom det er inkludert en del definisjoner med

relevans til brukerne av systemet. Blant annet defineres kolonnerekkefølgen på de eksporterte

CSV filene i dette dokumentet.

1.2 Dokumentets rolle i prosjektet

Kravspesifikasjonen har hatt en mangfoldig rolle for systemet. Den har vært til god veiledning

for GUIet av systemet og den har også lagt fundament for innholdsstruktur og database

struktur. Ellers har den også vært nyttig for å kommunisere systemet med oppdragsgiver og

veileder og har derfor hatt en direkte effekt på utviklingen av systemet.

1.3 Ordforklaring

Ord/uttrykk Betydning

Skjema Ett webskjema som ofte inkluderes på landingssider

for å registrere informasjon for brukere.

Kategori Skjemaer kan bli gruppert etter kategorier.

Lead En individuell skjemainnsending gjennom ett

webskjema med informasjon som gjør at

innsenderen kan oppfølges som en potensiell kunde.

Utmccn En cookie verdi som brukes av Google Analytics

som sier noe om hvordan brukeren har funnet frem

til nettstedet.

Url parameter En parameter i spørredelen av en URL.

En url parameter er den uthevede delen av denne

eksempel urlen:

http://www.example.com?urlparam=50


2. Om systemet

Mamut ASA ønsket ett å få utviklet ett nytt system for å generere webskjemaer for innsamling

av lead fra kampanjeaktiviteter. Det eksisterende CMS systemet og den nåværende rutinen for

registrering av leads har svakheter som både har negativ virkning på det totale salget og

tilgjengelige ressurser. Det nye systemet har som mål og strømlinjeforme og automatisere

leadinnsamlingen så mye som mulig og dermed løse opp flokene som er tilstede.

Løsningen vil i stor grad være en Microsoft orientert løsning. Det vil bli utviklet i IDEen

Visual Studio 2010 i rammeverket ASP.NET/ C# med en backend MSSQL database.

2.1 Om bedriften

Mamut (OSE “MAMUT”) ble etablert i 1994 og er en

ledende leverandør av administrative

programvareløsninger og Internettbaserte tjenester til små

og mellomstore virksomheter i Europa. Mamut tilbyr

løsninger for økonomistyring/regnskap, salgsstøtte, kunde-

og kontaktoppfølging (CRM), innkjøp/logistikk,

lønn/personal, prosjektstyring, e-handel, domener, e-post og webhotell. Mer enn 400.000

kunder i Europa forenkler hverdagen med løsninger fra Mamut.

2.2 Opprinnelig situasjon vs. ønsket situasjon

Det gjeldende CMS systemet hos Mamut som brukes til å generere webskjemaer har ingen

integrering med sporingseffekter som kan gi nyttig informasjon til markedsførerne. Dette

innebærer at sporingskoden må manuelt flettes inn i hvert eneste skjema. Dette er en ugunstig

manuell rutine som følger med seg samtlige ulemper:

1. man har ingen styring over hvilke skjemaer som samler inn kode

2. manuell innfletting krever programmering kompetanse

3. manuell innfletting åpner muligheten for brukerfeil som kan forårsake tap av sporingsdata

og lavere datakvalitet

4. manuell rutine krever ressurser som kan spares

Det er også en besværlig prosess å opprette selve skjemaene. Det nye systemet vil ha som mål

å løse problemer ved prosessen. Her har vi også mulighet til å legge til ekstra funksjonalitet

som mangler i det eksisterende CMS systemet som kan bidra til bedre effektivitet.

Det største problemet derimot er at selgerne i dag er avhengig av e-postveksling for å

registrere og følge leads. Leadsene går gjennom flere manuelle poster før de blir tatt opp og

det er sannsynlig at de blir forkastet på veien. Dette systemet vil redusere de manuelle rutiner

til ett minimum og sørge for høyere datakvalitet.


Opprinnelig situasjon

I diagrammet over kan vi se at salgsadministrator må hente ut leads fra databasen manuelt.

Videre må vedkommende filtrere bort ugyldige leads og manuelt sende leadinfoen videre til

en selger. Her skjer det nok en manuell rutine hvor selgeren må registrere leadet i CRM

systemet.

Ønsket situasjon

I den ønskede situasjonen skal systemet som tidligere nevnt blant annet fjerne manuelle

rutiner. Blant annet skal ikke salgsadministrator behøve å hente leads manuelt, men de skal

automatisk bli eksportert fra systemet på en periodisk basis. Filtrering av leads kan da skje

digitalt og leads skal importeres inn i CRM systemet utenom å gå igjennom selgere.

Merk at systemet mitt er begrenset til å eksportere leadsene fra databasen. Filtrering av leads

og videre utover i kjeden utføres av andre systemer.


2.3 Mål med systemet

Ressursbesparelser gjennom automatisering av rutineoppgaver.

Øke datakvalitet ved å fjerne manuelle rutiner.

Gir bedre informasjon i forhold til hvilke prosjekter som selger.

Reduserer svinn av leads.

Øke salget gjennom bedre oppfølging av leads.

3. Roller

Systemet vil hovedsakelig bli brukt av webutviklere og salgsadministrator. Webutviklere

oppretter, fletter inn og vedlikeholder skjemaer mens salgsadministrator kontrollerer og

eksporterer skjemadata.

Grunnet systemets natur er det ikke prioritert å implementere rolleinndelinger. Systemet vil

bare bli brukt internt og av få personer, derfor føler vi ikke at rolleinndeling er en essensiell

del av funksjonaliteten.

4. Språk

Hele systemet vil være på engelsk med unntak av landsspesifikk tekst. Det vil bli gjort tiltak

for å gjøre internasjonal tekst forståelig for engelsklesende personer i den konteksten de

befinner seg i.

4.1 Språkliste

Følgende språk vil kreve landsspesifikk tekst:

Norsk

Svensk

Dansk

Engelsk

Nederlandsk

Tysk


5. Database

Database diagram


Databasen som blir brukt er av typen Microsoft SQL Server (MSSQL). MSSQL er en

relasjonell modell database utviklet av Microsoft for bruk med Windows kompatible

applikasjoner.

Under følger en liste over definerte tabeller og felter i databasen.

Legg merke til at alle felter er i utgangspunktet NOT NULL og blir ikke nevnt eksplisitt i

definisjonen. Null felter blir definert med betegnelsen Nullable.

Forms

FormId Integer PK, AI

Name Varchar (250) UK

DateCreated Datetime

DateLastEdit Datetime Nullable

CountryId Integer FK [Countries: CountryId],

ON UPDATE: CASCADE,

ON DELETE: RESTRICT

CategoryId Integer FK [Categories: CategoryId],

ON UPDATE: CASCADE,

ON DELETE: RESTRICT

Redirect Varchar (250)

UseReplyEmail Tinyint

ReplyEmailFrom Varchar (250)

ReplyEmailBccto Varchar (250)

ReplyEmailSubject Varchar (250)

ReplyEmailText Varchar (MAX)

EnableNoLeadDetection Tinyint

Fields Felter som assosieres med skjemaer.

FieldId Integer PK, AI

FormId Integer FK [Forms: FormId], ON

UPDATE: CASCADE,

ON DELETE: CASCADE

Active Tinyint

Name Varchar (100)

FieldType Integer

Order Integer

Required Tinyint

DataType Integer

CodeGenerationSettings Tabell som lagrer tidligere brukte innstillinger for generering av kode.

CodeGenerationSettingId Integer PK, AI



UPDATE: CASCADE,

ON DELETE: CASCADE

TemplateStyle Integer

Width Integer

SubmitButton Varchar (100)

SubmitButtonType Integer

SubmitButtonImg Varchar (200)

SubmitButtonImgHover Varchar (200)

SubmitButtonOnclick Varchar (255)

FormOnsubmit Varchar (255)

UseAjaxForValMessages Tinyint

CleanFillFieldsScript Tinyint

Categories Kategorier skjemaer kan bli segmentert etter.

CategoryId Integer PK, AI

Name Varchar (250) UK

Formdata Data for skjemaer (leads)

FormdataId Integer PK, AI


UPDATE: CASCADE,

ON DELETE: CASCADE

DateSubmitted Datetime

Url Varchar (250) Url hvor skjema ble fylt ut

Project Varchar (250)

GoogleUtmccn Varchar (250)

FieldsFormdata Skjemadata fra feltene assosiert med skjema.

Forklaring:

En skjemadefinisjon har flere felter og når en bruker sender inn skjema med data så blir

feltene i skjemaet brukeren fylte ut og verdiene av disse lagret her. Man kan da gjøre en

kryssreferanse mellom feltene og verdiene som ble fylt ut av brukeren mot feltene som er

definert i skjemaet.

FieldFormdataId Integer PK, AI

FormdataId Integer FK [Formdata: FormdataId],

ON UPDATE: CASCADE,

ON DELETE: CASCADE

FieldType Integer

Name Varchar (150)


Value Varchar (250)

FormdataExports Denne tabellen brukes for å flagge eksporterte leads som eksportert eller ikke eksportert.

FormdataExportId Integer PK, AI

FormdataId Integer UK, FK [Formdata:

FormdataId], ON UPDATE:

CASCADE,

ON DELETE: CASCADE

Exported Tinyint

Exports Data om utførte eksporteringer.

ExportId Integer PK, AI

ExportDate DateTime

NumLeads Integer

Type Integer

Result Integer

CustomUrlParameters Her defineres egendefinerte url parametre som blir flettet inn sammen med skjema under

innsending og assosiert med ett lead. CustomUrlParameterType Integer PK

Name Varchar (250)

CustomUrlParametersFormdata Paramaterdata assosiert med skjemadata. CustomUrlParameterFormdataId Integer PK, AI

FormdataId Integer FK [Formdata: FormdataId],

ON UPDATE: CASCADE,

ON DELETE: CASCADE

CustomUrlParameterType Integer FK [CustomUrlParameters:

CustomUrlParameterType],

ON UPDATE: CASCADE,

ON DELETE: CASCADE

Value Varchar (250)

ProjectUrlParameters Her defineres hvilke url parametre som sjekkes for å finne Project verdien i skjemadata.

ProjectUrlParameterId Integer PK, AI

Name Varchar (250)

Priority Integer


Settings Her lagres globale konfigurasjoner. Samtlige urelatert funksjonalitet bruker denne tabellen til

å lagre persistente data. Blant annet google utmccn, automatisk eksportering innstillinger og

logging bruker denne tabellen.

Name Varchar (250) PK

Value Varchar (250)

Users Brukere av systemet.

UserId Integer PK, AI

Username Varchar (100)

Password Char (32)

CookieLogin Felt for å lagre informasjon om persistente innlogginger ved bruk av cookies.

CookieLoginId Char (23) PK

UserId Integer FK [Users: UserId], ON

UPDATE: CASCADE,

ON DELETE: RESTRICT

MachineName Varchar (100)

Platform Varchar (100)

Browser Varchar (100)

Countries Landene som brukes i systemet.

CountryId Integer PK

Name Varchar (100)

CountriesLanguages Tabell som binder tabellene Countries og Languages sammen.

CountryId Integer PK, UK, FK [Countries:

CountryId], ON UPDATE:

CASCADE, ON DELETE:

RESTRICT

Languages Integer PK, FK [Languages:

LanguageId], ON UPDATE:

CASCADE, ON DELETE:

RESTRICT

Languages Språkene som brukes for å hente ressurser på språk.

LanguageId Integer PK

Name Varchar (100)

CultureName Varchar(10)


Resources Her lagres ressursstrenger. Internasjonalisering er også støttet.

Name Varchar (250) PK

Value Varchar (250)

LanguageId Integer PK, FK [Languages:

LanguageId], ON UPDATE:

CASCADE, ON DELETE:

RESTRICT

ResourceCategoryId Integer PK, FK

[ResourceCategories:

ResourceCategoryId], ON

UPDATE: CASCADE,

ON DELETE: RESTRICT


Aktiviteter

Innlogging og utlogging av systemet.

Endring av brukerpassord.

Opprettelse og håndtering skjema.

o Generering av kode.

o Visning av innhentet data.

Opprettelse og håndtering av kategorier.

Automatisk og manuell eksportering av leads (skjemadata) til CSV format med fast

kolonnebredde.

Endre innstillinger for lagring av informasjon for analyseringsbruk.

Endre innstillinger for loggføring av systemtilbakemeldinger.

Aktiviteter og roller


6. Innholdsstruktur

Systemet er delt inn i flere seksjoner for å segmentere innholdet. Seksjonene listes opp og

beskrives under:

Seksjon Beskrivelse Aktiviteter

User Her legges sider med funksjonalitet

som pårører brukeren. Change password

Login

Logout

Forms Her legges sider som er knyttet til

opprettelsen, håndteringen og

bruken av skjemaer.

List all (index)

Create new

Edit form

Edit fields

Generate form code

View formdata

Categories Her legges sider som er knyttet til

opprettelse og håndtering av

kategorier.

List all (index)

Create new

Edit

Analysis Her legges sider som er mest

aktuelle for analysering av dataen

som blir matet inn med skjemaene.

Overview (index)

Google utmccn

Project URL parameters

Custom URL parameters

Export Her legges sider som pårører

eksportering av skjemaleads, samt

konfigureringer som er relaterte til

automatiske eksporteringer.

Overview (index)

Manual export

Automatic export settings

Logging Her legges sider som pårører

funksjonalitet relatert til logging. Overview (index)

Log

Settings

NB:

Merk at filstrukturen ikke er den samme som innholdsstrukturen på grunn av at systemet

kodes i MVC mønsteret.

Innholdsstrukturen er derimot en nøyaktig indikator på hvordan sluttbrukeren opplever

systemet.

Innholdsstruktur vs. MVC

Seksjonene kan sammenliknes med ”controllers” og aktivitetene kan sammenliknes med

”actions”.


Innholdsstruktur diagram


7. Grensesnitt

7.1 Hovedmeny

Hovedmenyen er delt inn i seksjonene som er oppgitt i innholdsstrukturen. Den vil bli plassert

på høyre siden av innholdet for å ikke stå midt i fokus, men alltid være lett tilgjengelig.


7.2 Seksjon: User

7.2.1 Login

Formål

Logge seg inn på systemet.

Forklaring av grensesnitt

Type Felt Beskrivelse

Tekstboks Username Brukernavn

Tekstboks Password Passord

Checkbox Remember me Om brukeren skal huskes ved senere

besøk

Knapp Login Logger deg inn i systemet

Unntak

Ved feil brukernavn eller passord vil en feilmelding vises og brukeren blir ikke logget

inn i systemet.


7.2.2 Change password

Formål

Endre bruker passord.



Tekstboks Old password Gammelt passord

Tekstboks New password Nytt passord

Tekstboks Confirm

password

Bekreftelse av nytt passord

Knapp Update Utfører endring av passord

Unntak

Følgende logikk må stemme for at feilmelding ikke skal oppstå:

o Old password må være likt det gamle passordet

o New password og confirm password må være like

o New password kan ikke være likt som old password


7.3 Seksjon: Forms

7.3.1 Create form

Formål

Opprette nytt webskjema.



Tekstboks Name Navn på skjema

Dropboks Country Hvilket land skjemaet skal registreres i

Dropboks Category Hvilken kategori skjemaet skal tilhøre

Knapp Create Oppretter skjema

Unntak

Tomt navn er ikke tillatt og feilmelding vil vises.


7.3.2 Edit form

Formål

Endre generell informasjon om skjemaet.



Tekstboks Name Skjemanavn

Dropboks Category Kategorien som skjemaet er knyttet til

Tekstboks Redirect Hvilken side brukeren skal bli send til

etter innsending av skjema

Radio HTML/Text Om e-mail skal bruke HTML format

eller i rentekst

Tekstboks From Hvem som vises i ”Fra” feltet

Tekstboks Bcc to Hvem som skal få en blind kopi av e-

mailen

Tekstboks Subject Emne på e-mailen

Tekstområde E-mail tekst Innholdet i e-mailen

Checkboks Enable no lead

detection

Om skjemaet skal bli sjekket for at leads

har kommet inn den siste perioden


Unntak

Name feltet kan ikke være tomt.

Redirect feltet må være en gyldig nettadresse (bruke http eller https protokoller og ha

gyldig hostname) eller tomt

From feltet må være utfylt og en gyldig e-mail om reply e-mail brukes.

Bcc to feltet må være en gyldig e-mail om fylt ut


7.3.3 Edit fields

Formål

Endre skjemaets felter.



Hakeboks Active Om feltet skal bli inkludert i

genereringen

Tekst Field Internasjonale navnet på feltet.

Engelsk versjon av feltnavnet står i

parantese for å hjelpe utvikleren.

Tekstboks Order Hvilken rekkefølge feltet skal vises i.

Lavere tall blir prioritert først

Dropdown-

boks

DataType Hva slags datatype feltet skal vises og

tolkes som

Hakeboks Required Om feltet skal være nødvendig eller ikke

Knapp Update Utfør lagring av endringer


7.3.4 Generate formcode

Formål

Generere HTML kode for skjemaet, som deretter kan kopieres og limes inn på en

nettside.

Bistå med valgmuligheter som gjør det enklere for webutvikleren å integrere skjemaet

på nettsiden.



Dropdown Template style Hvilken mal (ang. designet) skjemaet

skal bruke

Hakeboks Clean + fill fields

script

Om skjemaet skal bruke ”rengjør” og

”fyll felt” script.

Dette vil si at når brukeren trykker på

feltet så renskes teksten, og teksten

opprettes igjen om boksen er tom

Tekstboks Width Bredden på skjemaet

Dropdown Submit button Typen innsendingsknapp.

Valgene er tekst eller bilde.

Om bilde blir brukt vil det vises to nye

tekstboksfelt: original og hover.

Her oppgir man url til original og hover

bilde som skal brukes.

Tekstboks Submit button Teksten på innsendingsknappen.

Tekstboks Submit button

onclick

Kode som skal settes inn i onclick

attributtverdien på innsendingsknappen

Tekstboks Form onsubmit Kode som skal settes inn i onsubmit


attributtverdien på skjemaet

Checkbox Use ajax for

validationmessages

Om ajax skal brukes for å hente

valideringsbeskjeder, eller om de skal

genereres direkte inn i koden

Knapp Generate Genererer kode

Unntak

Bruk av anførselstegn i onclick/onsubmit feltene er ikke tillatt.


7.3.5 View formdata

Formål

Vise dataene som er sendt inn med skjemaene.


7.3.6 List forms

Formål

Vise oversikt over opprettede skjemaer.

Vise leadrelevant informasjon slik som hvilke skjemaer som er mest brukt og hvilke

som er aktive.



Dropdown Show Hvilken mengdegruppe med skjemaer

som skal vises

Tekst ID Det unike ID nummer til skjemaet

Tekst Name Navnet på skjema

Tekst Category Navn på kategorien til skjema

Tekst Country Landet skjemaet ble opprettet i

Tekst Date created Når skjemaet ble opprettet

Tekst Last submittion Når skjema sist ble brukt

Tekst Total submits Totalt antall personer som har sendt inn

data med skjema

Man kan sortere både asc og desc ved å trykke på en av overskriftene

Skjemaene blir delt inn i sider for å begrense antall skjemaer per visning. Hver side kan

inneholde 50 skjemaer.


7.4 Seksjon: Categories

7.4.1 Create category

Formål

Opprette kategori



Tekstboks Name Navnet til kategorien

Knapp Create Oppretter kategori

Unntak

Tomt name verdi er ikke tillatt og feilmelding vil vises.


7.4.2 Edit category

Formål

Endrer kategori



Tekstboks Name Navnet til kategorien

Knapp Update Oppdaterer kategori

Unntak

Tomt name verdi er ikke tillatt og feilmelding vil vises.


7.4.3 List categories

Formål

Vise oversikt over opprettede kategorier.



Dropdown Show Hvilken mengdegruppe med kategorier

som skal vises

Tekst ID Det unike ID nummer til kategorien

Tekst Name Navnet på skjema

Man kan sortere både asc og desc ved å trykke på en av overskriftene

Kategoriene blir delt inn i sider for å begrense antall skjemaer per visning. Hver side

kan inneholde 50 kategorier.


7.5 Seksjon: Analysis

7.5.1 Analysis Overview

Formål

Vise nyttig lead informasjon


7.5.2 Google utmccn

Formål

Kontrollere lagring av google analytics cookie verdi sammen med skjemadataen.



Hakeboks Enable storage

of utmccn value

Valget mellom å lagre utmccn verdien

eller ikke

Knapp Update Lagrer endringene


7.5.3 Project Url parameters

Formål

Opprette og håndtere henting av kampanjekoder (vil bli lagret i project feltet i

skjemadata tabellen).



Tekstboks Value Parameteren i urlen som vil bli forsøkt

hentet

Tekstboks Priority Hvilken prioritet parameteren vil ha.

Prioriteten går fra lavest til høyest.

Knapp - (minus) Fjerner en parameter

Knapp Update Oppdaterer endringene

Knapp Add new Legger til ny parameter

Unntak

Tom ”Value” verdi er ikke tillatt og feilmelding vil vises.


7.5.4 Custom Url parameters

Formål

Endre brukerdefinerte parametre som blir flettet inn sammen med lead data.



Tekstboks Parameter Parameteren i urlen som vil bli forsøkt

hentet

Knapp Update Oppdaterer endringene


7.6 Seksjon: Export

7.6.1 Export Overview

Formål

Vise nyttig informasjon om tidligere eksporteringer.


7.6.2 Manual export

Formål

Eksportere skjemadata til CSV fil manuelt.



Dropdown Country Hvilket land det skal filtreres på

Dropdown Category Hvilken kategori det skal filtreres på

Tekst/kal. Date from Startdato for dataen som skal

eksporteres

Tekst/kal. Date to Sluttdato for dataen som skal

eksporteres

Knapp Export Eksporterer skjemadata

Unntak

Startdato og sluttdato må være oppgitt.

Startdato må være før sluttdato.


7.6.3 Automatic export basic

Formål

Endre innstillinger som pårører automatisk eksportering av skjemadata.



Dropbox Run export Definering av intervall mellom hver

automatisk eksportering

Checkbox Unexported leads

only

Om bare ueksporterte leads skal

eksporteres

Dropbox Mode Om eksporteringen er markert som

startet eller stoppet

Knapp Update Lagring av innstillinger


7.6.4 Automatic export advanced

Formål

Endre innstillinger som pårører automatisk eksportering av skjemadata.



Textbox Service update

interval

Hvor ofte servicen skal oppdatere seg

selv med data fra datbasen. Verdi oppgis

i minutter.

Textbox Trigger

parameter value

Verdien som må matche verdien i url

parameteren ”Trigger” for at automatisk

eksportering skal gjennomføres på

eksporteringssiden.

Textbox E-mail to Hvis spesifisert, hvilken e-mail konto

den eksporterte filen skal sendes til


Unntak

”Service update interval” feltet kan bare bestå av tall og tallet må være mellom 5 og 120

”E-mail to” feltet hvis oppgitt må være en gyldig e-mail

”Trigger parameter value” kan bare bestå av bokstaver og tall


7.7 Seksjon: Logging

7.7.1 Logging overview

Formål

Vise nyttig loggføring informasjon.


7.7.2 Log

Formål

Vise innholdet i loggen.


7.7.3 Log Settings

Formål

Endre innstillinger som pårører loggføring og effekter av dette.



Textbox E-mail to send

log messages

E-mailen log beskjeden skal bli sendt

Checkbox Send e-mail at

occourence

Om det skal sendes en e-mail av typen

”Type” når en logginnføringen av

samme typen forekommer

Dropdown No lead

detection

trigger time

Antall timer som må ha gått for å utløse

”no lead detection” feilen


Unntak

”E-mail to send log messages” feltet må være en gyldig e-mail


8. Funksjonalitet og spesifisering

Her skrives detaljer om funksjonalitet som krever ekstra definering og forklaring.

8.1 Generering av skjemakode

Skjemakoden som blir generert på serveren vil være statisk og må derfor være uavhengig av

server-side språk. Denne koden er ment for å bli flettet inn i en statisk HTML side så koden

kan bare bestå av html og javascript (om dynamisk funksjonalitet er ønskelig).

Ettersom statisk kode ikke kan endres automatisk fra en kilde i ettertid er det ønskelig å følge

noen basiske prinsipper for å gi mest mulig fleksibilitet og minst mulig avhengigheter i den

genererte koden.

Prinsippene er som følger:

Generer så lite kode som nødvendig

Hold skjemaene så uavhengige som mulig

Marker klart hva som er generert kode og når skjemaet starter og ender (kommentarer)

Referer til en eksisterende javascript fil istedenfor å generere javascript om mulig

Referer til en eksisterende css fil istedenfor å genererer inline stiler om mulig

Skjemafelter

Legend:

ID/Name: Brukes til å definere html elementets id og navn

Feltnavn: Navnet på feltet

Datatype: Feltets datatype

Validering(er): Hva slags klient-side valideringer som skal genereres for feltet

Betingelse for visning: Hvilke betingelser som må være sanne for at feltet skal genereres

ID/

Name

Feltnavn Datatype Validering(er) Betingelse

for

visning

Kommentar

Field[Feltets

ID]

Company Tekstboks Required Alltid Landsspesifikt

navn

" Name Tekstboks Required " Landsspesifikt

navn

" Email E-mail Required

E-mail

" Landsspesifikt

navn

" Phonenum Telefonnummer Required

Telefonnummer

" Landsspesifikt

navn

" Custom1 Valgfritt [Kommer ann

på datatype…]

Hvis aktiv Valgfritt navn

" Custom2

" Custom3

" Custom4

" Custom5

FormId FormId Hidden Aldri Skjemaets ID

slik at

skjemadataen

kan knyttes til


skjema

Eksempel:

<input type=”text” name=”Field1234” id=”Field1234” value=”Company name here…” />

<input type=”hidden” name=”FormId” id=”FormId” value=”123” />

Generering av Javascript

Det må genereres valideringer for alle felter som krever validering. Dette krever en tett

knytning mellom serveren og klientside kode. Systemet vil prøve å gjøre denne knytningen så

oversiktsbar og så lett å vedlikeholde som mulig. For å oppnå dette har vi laget ett bibliotek

som brukes å generere klientside kode på en objektorientert måte. En annen fordel er at

byggingen av javascript kode blir ”strong-typed” og feil skal da i prinsippet oppdages under

kompilering. Det hjelper derimot ikke mot endringer i javascript biblioteket; alle endringer i

javascript biblioteket må foretas på serversiden også.

Under følger ett diagram som illustrerer hvordan klientside kode blir generert på serversiden:

Diagram som viser prinsippet i generering av klientside kode på serversiden.

8.2 Prosessering av skjemadata

NB: Denne delen er nært knyttet til 8.1 Generering av skjemakode.

Ved prosessering av skjemadata må man ta til betraktning at skjemaene ligger ute på det

offentlige verdensveven og må derfor ikke stole på dataen som kommer inn. Muligheten for at

data som sendes inn er tuklet med er kanskje usannsynlig, men absolutt reell. Systemet må

sørge for å ikke bli korrupt ved ondsinnet input.

Valideringer

Følgende valideringer utføres for å sørge for en trygg prosessering:

Hva Valideringer Aksjon hvis ikke validert:

Felt ID Feltets ID må i database tabellen ha referanse til

samme skjema ID som feltet FormId Ignorer

FormId Skjema må eksistere i databasen Forkast skjemadata

NB: Det er tatt forbehold for at feltverdier filtreres etter eksportering derfor gjøres det ingen

validering her.


NB2: Ikke ta for gitt at alle feltene i skjemaet blir lagret og assosiert med skjema (dette gjelder

også Company, Name, E-mail osv…). Bruk default verdi (som regel tom streng) hvis feltet

ikke finnes.

Tilbakemelding e-mail

En e-mail med tilbakemelding skal sendes tilbake til e-mail spesifisert i e-mail feltet sendt inn

med skjema om skjemaet bruker tilbakemelding e-mail.

Redirect

Man redirectes til urlen spesifisert i skjemaets redirect felt eller tilbake til nettsiden skjemaet

ble sendt inn fra (default).

Behandling av feil

Alle generelle feil under prosessering av skjemadata vil bli stille ignorert eller behandlet.

8.3 Generering av CSV fil ved eksportering

Definisjon for feltene til de genererte CSV filene følger under. Alle feltene vil bli plassert ved

siden av hverandre horisontalt med øverste felt til venstre og nederste felt til høyre.

Detaljer

Kolonne headers vil bli inkludert i første raden av CSV filen

Semikolon vil bli brukt som skilletegn mellom verdiene.

Semikolon og linefeeds funnet i verdier vil bli erstattet med space.

Navn Type Kommentar

LeadId Identifier IDen til leadet

Date submitted Dato Datoen når leadet ble registrert

FormId Identifier Skjemaet som leadet hører til

Category Identifier Kategorien skjemaet til leadet hører

til

Country Identifier Landet skjemaet til leadet hører til

Company Skjemafelt Firma

Name " Navn

Email " E-post

Phonenumber " Telefonnummer

Custom1 " Valgfrie felter

Hvis verdi er checkbox vil verdien

vises i boolean form (True / False). Custom2 "

Custom3 "

Custom4 "

Custom5 "

GoogleUtmccn Cookie Verdi hentes fra cookie

Project Url parameter Parameter som hentes fra urlen og

definerer prosjekt tilhøring til lead

CustomParameter1 Url parameter Flettes inn fra urlen og assosieres

med ett lead CustomParameter2 "

CustomParameter3 "

CustomParameter4 "

CustomParameter5 "


Url Url Url som viser hvor leadet kom fra

8.4 Manuell eksport

Man kan eksportere leads manuelt ved behov i tillegg til automatisk eksportering. Ved

manuell eksportering vil ikke leads bli flagget som eksportert.

Detaljer

Filnavnet som blir generert for brukeren når han/hun eksporterer vil ha syntaksen:

Manual-[dag 2 siffer][måned 2 siffer][år 2 siffer]-[time 2 siffer][minutt 2 siffer][sekund

2 siffer]-[millisekund]-[land]-[kategori].csv

o Land og kategori variablene vil bli strippet for alle tegn unntatt bokstaver og

tegn (regex: [a-zA-Z0-9])

8.5 Automatisk eksport

Leads skal automatisk eksporteres hvert døgn eller med en annen tidsintervall. For å få til

dette skal det brukes en Windows Service og en synlig side på webserveren som tar imot kall.

Alle leads som ikke allerede er flagget som eksportert vil bli flagget ved automatisk

eksportering.

Hendelsesforløp for automatisk eksportering:

1. Servicen sender en HTTP request til webserveren.

Denne nettsiden er beskyttet med en url parameter betingelse slik at ikke alle kan

triggere eksporteringen sporadisk.

2. Webserveren henter lead informasjon fra databasen og genererer en CSV fil til

serverns filsystem.

3. System prøver å laste opp den nylig genererte filen til en definert FTP server.

Filnavnet vil ha syntaksen:

[dag 2 siffer][måned 2 siffer][år 2 siffer]-[time 2 siffer][minutt 2 siffer][sekund 2

siffer]-[millisekund]-AUTO.csv

4. Rengjøring (sletting av midlertidig filer og liknende).


Handlingsflyten for automatisk eksportering

Dato og tid intervaller

Man kan definere dato- og tidsintervallene for automatisk eksportering ved bruk av to typer

verdier. Disse er intervalltyper og tidspunkter (hele timer). Ett eksempel er intervalltypen

Daily sammen med klokkeslettet 08:00. Sammen danner verdiene utgangspunktet for

kalkulasjonen av start dato begrensningen for gjeldende eksportering.

NB: Merk at HTTP requesten vil bli sendt 5 minutter før reell slutt dato. Dette er for å unngå

feil ved kalkulering av start og slutt dato.

Matchende tidspunkt: Dette begrepet brukes om tidligere nevnte tidspunkt som danner

utgangspunkt for start dato. Altså om tidspunktet er 08:00 så refererer uttrykket ”matchende

tidspunkt” til dette klokkeslettet.

Intervall Start dato Slutt dato

Daily Første dag før i tid med matchende

tidspunkt

Dato nå

Weekly Hver mandag med matchende tidspunkt 1 uke etter matchende

tidspunkt

Monthly Første dag i måneden med matchende

tidspunkt

1 måned etter matchende

tidspunkt


Eksempler:

Settings: Daily 08:00

Nå Start dato Slutt dato Kommentar

Ons 3. aug 07:00 Tir 2. aug 08:00 Ons 3. aug 08:00 En time før tidspunkt

Ons 3. aug 08:00 Tir 2. aug 08:00 Ons 3. aug 08:00 Matchende tidspunkt

Ons 3. aug 09:00 Ons 3. aug 08:00 Tor 4. aug 08:00 En time etter tidspunkt

Settings: Weekly 08:00


Man 1. aug 07:00 Man 25. juli 08:00 Man 1. aug 08:00 En time før tidspunkt

Man 1. aug 08:00 Man 25. juli 08:00 Man 1. aug 08:00 Matchende tidspunkt

Man 1. aug 09:00 Man 1. aug 08:00 Man 8. aug 08:00 En time etter tidspunkt

Tor 4. aug 08:00 Man 1. aug 08:00 Man 8. aug 08:00 En annen dag i uka enn

mandag

Settings: Monthly 08:00


Man 1. aug 07:00 Fre 1. juli 08:00 Man 1. aug 08:00 En time før tidspunkt

Man 1. aug 08:00 Fre 1. juli 08:00 Man 1. aug 08:00 Matchende tidspunkt

Man 1. aug 09:00 Man 1. aug 08:00 Tor 1. sep 08:00 En time etter tidspunkt

Tor 4. aug 08:00 Man 1. aug 08:00 Tor 1. sep 08:00 En annen dag i måneden

enn første dagen

Kommentar i forhold til scheduled tasks

Fordelen med å bruke en Windows Service er at det er ingen avhengighet med

eksporteringstid mellom tasktidspunkt og database eksporteringsinnstillinger. Med Service så

har man muligheten til å dynamisk synkronisere timerne med databasen automatisk.

Service logikk

Servicen bruker to timere til å kalkulere når automatisk eksportering skal skje, samt

synkronisere database innstillingene med servicen. Den ene timeren snakker med databasen

med en fast intervall og sjekker om database innstillingene har endret seg. Hvis dette er

tilfellet så oppdateres innstilingene og den andre timeren må omstilles. Den andre timeren har

en variabel intervalltid og innstiller seg etter innstillingene satt i databasen. Den bestemmer

når den automatiske eksporteringen skal skje.

E-mail

Om ”send leads to email” feltet er spesifisert vil det sendes en e-mail med leads som vedlegg

til den spesifiserte e-post kontoen.

Under følger spesifikasjonen for e-mailen som sendes:

Headers From: [email protected]

To: [Mail oppgitt i logging innstillingene]

Subject: Automatic export triggered on [date] in MamutWebforms

Body This e-mail has been sent as automatic export has been triggered in

MamutWebforms.

mailto:[email protected]


Leads has been converted into CSV format and included in this e-mail as an

attachment. The leads that are included are submitted between the dates [start

date]-[end date].

8.6 Loggføring

Alle logginnføringer vil bli lagret til en loggfil. En e-mail kan bli sendt til en valgfri e-post

adresse om innstillingene tillater det.

Hva loggføres

Databasefeil

Eksporteringsfeil

No lead detection feil (om skjema ikke har fått lead på ett spesifisert antall timer

registreres det som en feil)

Service feil

E-mail feil

o Feil som oppstår fordi at mottaker ikke finnes blir ikke logget

o NB: E-mail feil kan ikke sendes med e-mail og det reflekteres i systemet

Logginnførelser

Merk at nye innføringer vil bli lagt til før det eksisterende innholdet i loggen. Altså nyeste

innlegg forekommer øverst i loggen.

Felter:

Navn Datatype Kommentar

Datetime Dato Dato og tidspunkt for feilen

Type Streng Typen feil

Context Streng I hvilken kontekst feilen ble logget i

Subject Streng Kort introduksjon om innholdet

Message Streng Inneholder melding, kilde, linjenummer

og callstack for feilen

Data Nøkkel-verdi par Ekstra informasjon. Kan være tom og

vil da returnere en tom streng istedenfor.

Oppset:

--- Log entry for [datetime]

--- Type: [type]

--- Context: [context]

--- Subject: [subject]

--- Message

[message]

--- Additional data

[data]

------------------------------------------------------------------------------------


Legg merke til at loggmeldingene avsluttes med tre linjeskift.

E-mail oppsett

Headers From: [email protected]

To: [Mail oppgitt i logging innstillingene]

Subject: An error of type ' [type] ' occoured in contex ' [context] ' in

MamutWebforms with message: [subject]

Body An error of type ' [type] ' occoured in contex ' [context] ' in MamutWebforms.

Read below for details.

--- Message:

[message]

--- Additional data:

[data]

8.7 Feilbehandling

NB: Denne delen er nært knyttet til 8.6 Loggføring.

Her skrives detaljer om behandling av runtime feil i systemet.

Type Feil Aksjon

Generelt Generelle feil - Ignorer

Database Alle feil - Logging

- Send e-mail*

E-mail Generelle feil - Logging

E-mail Finner ikke mottaker - Ignorer

Eksport Feil i automatisk

eksportering

- Logging

- Send e-mail*

Eksport Feil i manuell

eksportering

- Logging

- Gi øyeblikkelig tilbakemelding

No lead

detection

No lead detection feil

er triggret for ett

skjema

- Logging

- Send e-mail*

Service Alle feil - Logging

- Send e-mail*

* Bare om e-mail innstillingene tillater dette.

mailto:[email protected]


Ressurshåndtering

Systemet krever ett håndteringssystem for ressurser ettersom at skjemaene må støtte flere

språk i visse sammenhenger. Det er ønsket at enkelte ressurser skal kunne endres dynamisk,

derfor blir ressursene lagret i databasen for mest mulig fleksibilitet.

8.8 Ressursoversikt

8.8.1 Valideringsfeilmeldinger

SummaryText

RequiredMustHaveValue

OnlyDigitsAreAllowed

InvalidEmail

InvalidPhonenum

8.8.2 Default (forhåndsvalgte) feltverdier

Default verdier for felt navn, datatype, rekkefølge, aktiv (om feltet er aktivt) og nødvendig

(om feltet må være fylt ut) for følgende felter:

Company

Name

Email

Phonenum

Custom1

Custom2

Custom3

Custom4

Custom5

Når skjemaer opprettes så fylles feltene inn med default verdiene nevnt ovenfor. Vi trenger i

tillegg å bruke lokalisering for å fylle inn med landsspesifikk språk på feltnavnene.


9. Forbindelse mellom system og webskjema

Dette kapittelet er dedikert til å gi mer oversikt levetiden til webskjema; fra genereringen av

skjemakoden på serveren, til innflettingen av skjema på nettside, til prosesseringen av tilsendt

skjemadata på serveren.

9.1 Rollene

Systemets rolle er å generere html og scripts for å:

1. Lage stilert, standard skjema

2. Kunne hente nødvendig data ved skjema postback

3. Validere skjema før innsending

Skjemaets rolle er å hente inn data fylt ut av brukeren og sende dataen videre til serveren.

9.2 Data fra skjema til server

Hva Formål

Feltdata Lagre informasjon om leadet

Cookies Lagre google analytics cookie verdi

Url Lagres for å lokalisere hvor skjemaet lå når det ble fylt ut og

innsendt

Urlparametre Lagre tilleggsinformasjon om leadet


Forbindelsen mellom system og webskjema


10. Tilgangsbegrensning

Systemet vil være beskyttet med brukernavn og passord.

11. Design

Designet vil være rent og gå i tråd med Mamut sine design prinsipper.

11.1 Prinsipper

Designprinsippene som skal brukes er:

Funksjonelt orientert. Det funksjonelle skal ikke gå til spille for ett overdådig eller

pompøst design.

Moderne og elegant med vekt på enkelthet.

Profesjonalitet.

11.2 Farger

Fargene som skal gå igjen skal være nyanser av blå, hvitt og grått. Gult og oransje kan brukes

som kontrast for å fremheve elementer eller gjøre brukersnittet mer appellerende.

12. Programmeringsmønster (ASP.NET MVC2)

MVC står for Model-View-Controller. Model er ett objekt som representerer data eller en

tilstand. Controller er lederen om du vil, som håndterer tilstanden til modellen og ofte

kommuniserer med datalagre slik som SQL databaser. Controlleren sender en ferdig

behandlet modell til en View som basert på modellen viser ett visuelt grensesnitt.

Dette programmeringsmønstret er bygget på samtlige prinsipper:

Skille mellom design og programmering. Designere trenger bare å forholde seg til det

som finnes i View.

Rolleoppdelingen til MVC gir mer logisk segmentering av strukturen og det blir

enklere å fordele oppgaver til passende instanser.

Ved å isolere de ulike delene kan man teste og vedlikeholde dem uavhengig av

hverandre.

13. Kodekonvensjon

All kode i systemet vil prøve å følge en kodekonvensjon som er mest mulig lik

industristandarden for .NET/C#. Dette vil gjøre det lettere å sette seg inn i koden for andre

utviklere.

Standard: http://msdn.microsoft.com/en-us/library/xzf533w0%28v=VS.71%29.aspx

http://msdn.microsoft.com/en-us/library/xzf533w0%28v=VS.71%29.aspx

Kravspesifikasjon Mamut Webforms 1 av 52 -...

Documents

Transcript of Kravspesifikasjon Mamut Webforms 1 av 52 -...