Channel Marketing – Rapoarte Speciale Pentru Clienti

Channel Marketing – Rapoarte speciale pentru clienți

Studiu de caz: DCI România SRL Brașov

Cuprins

Introducere

Cap. 1. Prezentarea mediului de lucru și a platformei WebTradeCenter

Prezentarea mediului de lucru

Aspecte teoretice privind managementul conținutului și portalurile

Conceptul WebTradeCenter

Cap. 2. Serviciul WTC Collaborative Marketing

Atribuțiile unui Collaborative Marketer

Descrierea rapoartelor și a indicatorilor

Descrierea aplicației

Cap. 3. Tehnologiile folosite în realizarea aplicației

3.1. Limbajul C#

3.2. Entity Framework – Code First

3.3. SQL SERVER Management Studio

3.4. Telerik Reporting

3.5. ASP.NET MVC și ASP.NET Web API

Introducere

Cap. 1. Prezentarea mediului de lucru și a platformei WebTradeCenter

1.1. Prezentarea firmei

DCI Database for Commerce and Industry România S.R.L.

DCI România SRL Brașov este o filială a companiei DCI Database for Commerce and Industry AG cu sediul în Starnberg, . Michael Mohr, directorul general actual, a fondat compania în anul 1993. În anul 2013 DCI AG a realizat o cifră de afaceri de 3,72 millioane de euro. Deține numeroase brevete naționale, europene și internationale în domeniul schimbului de date.

De la înființarea companiei în România, din anul 2001, numărul angajaților cu înaltă calificare a crescut de la 25 la 64 în prezent (situația în luna martie 2014), dintre care majoritatea sunt vorbitori de limba germană și engleză, iar câțiva dintre ei sunt certificați Microsoft. Compania aparține domeniului de creare a bazelor de date și de întreținere a acestora. Filiala din România este specializată în colectarea și verificarea datelor, precum și în preluarea manuală a acestora. În anul 2013 DCI România SRL a realizat o cifră de afaceri de 1.121.496 euro.

Departamentele Content, Development și Media fac posibilă oferirea următoarelor servicii:

WebTradeCenter (WTC) – o rețea de date pentru companii. Prin intermediul acesteia, companiile își pot procesa într-un mod optim datele provenite din surse variate, în scopuri și pentru grupuri țintă diferite, își pot conecta rapid clienții și partenerii de afaceri. Mai mult, acest portal permite concernelor internaționale o intrare rapidă pe piața din Europa. Principalul client al WTC-ului este Intel.

Digitalizare și creare de cataloage electronice

Calificare de date în domeniile IT / telecomunicații / electronice de consum / electrocasnice

Calificare conform standardelor : eCl@ss, UNSPSC, BMEcat

Creare și întreținere de site-uri

Creare și întreținere de HTML Premium Email pentru email marketing

Infoboard (WAi) – soluție Web pentru afișarea de newslettere și oferte speciale

Exemple de clienți de Content: DCI AG, Amazon, API, Billiger, Comstern, Devil, Ecotec, Herweck, IDG, Lexware, Jacob Computer, Mentasys, Synaxon, Sony, Intel.

Exemple de clienți de Email Marketing: Acer, BenQ, DELO, EPSON, HP, Hyundai, IBM, Logitech, Microsoft, Samsung, SonyEricsson, Symantec, Toshiba, Zyxel.

Exemple de clienți de Data Services: CONRAD, DHW, Häfele, Moeller.

Principalii parteneri de tehnologii :

Amazon Web Services – Platforma de cloud computing pusă la dispoziție de către Amazon.com este apreciată mai ales pentru viteza și eficiența sa. Amazon EC2 permite o implementare scalabilă a aplicațiilor, iar Amazon S3 oferă spațiu de depozitare cu ajutorul unor interfețe web.

Google – specializată în servicii și produse orientate către Internet, corporația multinațională are o gamă largă de activități, satisfăcând cerințele și ridicându-se întodeauna la standardele înalte cu care și-a obișnuit clienții.

Microsoft – multinaționala este cunoscută mai ales pentru excelența sa în domenii ca programarea, fabricarea, licențierea, susținerea și vânzarea de produse software, electronice și computere personale.

SalesForce – compania californiană excelează în domeniul cloud computing-ului, fiind cunoscută mai ales pentru CRM – ul pus la dispoziție. Industrii și companii de toate mărimile pot menține legătura cu clienții lor într-un mod plăcut și eficient, utilizând ultimele inovații în tehnologia mobilă și cloud.

1.2 Aspecte teoretice privind managementul conținutului și portalurile

O definiție plauzibilă a noțiunii de conținut : „Conținutul este reprezentat de „obiecte" din site-urile Web, care pot fi clasificate în două categorii :

Informații – text și imagini care se pot vedea pe un site web în momentul vizitării acestuia;

Aplicațiile și software-ul care rulează pe serverele site-ului Web și afișează informația către vizitatori." [Cătălin Maican, Radu Lixăndroiu, Sisteme informatice pentru managementul conținutului, pag.4].

Se poate observa cu ușurință că orice site este alcătuit din multiple tipuri de conținut : text, imagini, obiecte audio, obiecte video, acest lucru permițând specializarea instrumentelor. Sistemele de gestiune a conținutului pornesc de la conceptul de componentă de conținut, aceasta fiind stocată în depozite care utilizează același format.

Elementele unui sistem de gestiune a conținutului sunt :

Aplicația de gestiune a conținutului (CMA) care gestionează componentele de conținut cu ajutorul unei baze de date, a unui sistem de fișiere sau a unei combinații între cele două. Mai departe enumerăm etapele ce formează ciclul de viață al unei componente de conținut : design-ul, crearea, editarea, așezarea în document, testarea, staging, livrarea, întreținerea, arhivarea și eliminarea, totul putând fi efectuat doar dacă s-a obținut aprobarea, aceasta fiind dată de o persoană sau un comitet cu autoritatea necesară.

Aplicația de gestiune a metaconținutului (MMA) se ocupă cu gestionarea informațiilor despre componentele de conținut. Această aplicație permite delimitarea dintre conținut și livrarea acestuia, delimitare necesară deoarece CMA și MMA au fluxuri de lucru diferite și grupuri de utilizatori diferiți. Dintre tipurile de metaconținut putem enumera : șabloane, script-uri client și server, aplicații compilate server-side.

Aplicația de livrare a conținutului (CDA) se ocupă de afișarea componentelor de conținut pe Web.

Sisteme de management al conținutului (CMS)

„Un sistem de management al conținutului (CMS) este un sistem software utilizat la asistarea utilizatorilor săi în procesul de management al conținutului. " [Cătălin Maican, Radu Lixăndroiu, Sisteme informatice pentru managementul conținutului, pag.8].

Dintre funcțiile unui astfel de sistem putem enumera : identificarea și crearea de documente, identificarea utilizatorilor cheie, abilitatea de a atribui roluri diferitelor categorii de conținut, abilitatea de a urmări și organiza mai multe versiuni ale unei singure instanțe a conținutului, abilitatea de a publica conținutul, pentru a susține accesul la conținut.

Un sistem de management al conținutului oferă următoarele facilități cheie :

Șabloane automate

Conținut ușor editabil

Set scalabil de facilități

Upgrade-uri după standardele web

Managementul workflow-ului

Managementul documentelor

Portalurile

Pentru a putea înțelege ce presupune platforma WebTradeCenter trebuie să începem cu câteva aspecte teoretice legate de portaluri, arhitectura acestora, caracteristici și ramificații. Un prim aspect ce trebuie menționat este că portalurile au în mare parte aceleași funcționalități, infrastructură și mecanisme, chiar dacă conținutul si structura lor variază. Dintre funcțiile de bază ale unui portal putem aminti agregarea, autentficarea, personalizarea, căutarea, colaborarea și, evident, securitatea. În funcție de tipul de portal, aceste funcționalități pot varia, mai ales când vorbim despre securitate și personalizare.

Al doilea aspect presupune diferențierea acestora, în genere ele împărțindu-se în portaluri publice și portaluri la nivel de organizație.

„Portalurile la nivel de organizație sunt specifice organizației respective și evoluează în jurul organizației pe care o reprezintă" [Cătălin Maican, Radu Lixăndroiu, Sisteme informatice pentru managementul conținutului, pag.179], de unde deducem că misiunea principală a unui astfel de portal constă în promovarea produselor, serviciilor, imaginii și culturii organizației respective. Pe de altă parte, când ne referim la un portal public putem spune că scopul acestuia este „… de a transmite cât mai mult conținut posibil în vederea atragerii și reținerii unui număr cât mai mare de utilizatori web." [Cătălin Maican, Radu Lixăndroiu, Sisteme informatice pentru managementul conținutului, pag.179].

Având în vedere gama largă de subiecte și serviciile pe care le acoperă aceste portaluri, ele mai capătă denumirea de portaluri orizontale, urmând ca portalurile corporative să devină portaluri verticale sau vortaluri, scopul lor limitându-se la obiectul afacerii organizației respective.

Portaluri business-to-employee

Aceste portaluri își găsesc utilitatea în cadrul organizației venind în ajutorul angajaților și asigurând fluxul informațiilor într-un mod mult mai plăcut și eficient, creându-le acestora sentimentul de afiliere. Managerii adoptă lucrul cu aceste portaluri deoarece ele îmbunătățesc productivitatea angajaților și permit luarea unor decizii mult mai rapid. Alte avantaje ar fi facilitarea colaborării, eliminarea muncii pe hârtie sau chiar accelerarea procesării tranzacțiilor, asta în cazul organizațiilor mai mari. Nu trebuie să uităm de problema securității, aceasta necesitând o autentficare cât mai solidă.

Portaluri business-to-consumer

Deși există o tendință de a limita aceste tipuri de portaluri doar la portaluri de comerț electronic, aceasta este o abordare greșită, iar ele trebuie asociate „…cu toate tipurile de portaluri business-to-consumer, în care consumatorii ar fi atât clienții/consumatorii existenți cât și cei potențiali." [Cătălin Maican, Radu Lixăndroiu, Sisteme informatice pentru managementul conținutului, pag.186].

În general se pleacă de la o pagină web cu informații pe care organizația o deține deja, urmând ca portalul să evolueze din aceasta, informațiile adiționale fiind legate de tranzacții sau de funcțiile de tip self-service, iar autentificarea depinde de importanța informațiilor introduse în cadrul tranzacțiilor.

Portaluri business-to-business

Aceste portaluri se pot îndrepta spre două tipuri de activități, ori interacțiunea cu partenerii existenți, ori identificarea noilor oportunități de afaceri. Această delimitare face ca în final să se ajungă la două tipuri de portaluri : portaluri b2b specifice companiilor și portaluri publice b2b specifice afacerii. Prima categorie facilitează în special execuția tranzacțiilor, iar în cazul celei de-a doua scopul este de a acționa sub forma unei piețe comune.

Portalurile b2b mai au avantajul de a oferi acces controlat la aplicații de tip ERP, ceea ce vine în ajutorul partenerilor care pot partaja informații actualizate într-un mod mult mai dinamic și eficient.

Arhitectura de bază a portalurilor

Aceasta presupune :

interfață către web;

managementul interfeței cu utilizatorul;

mecanisme de acces la date externe;

servicii de management al datelor;

securitate, autentificare și personalizare;

instrumente de dezvoltare a portalului;

instrumente de administrare și management ale portalului.

1.3. Conceptul WebTradeCenter

Platforma WebTradeCenter își propune să vină în ajutorul a două categorii de participanți ai mediului de afaceri : pe de o parte companiile care au produse și informații de oferit, iar pe de altă parte clienții ce caută produse și informații. Problema ce intervine între cele două categorii este multitudinea de informații și modalitatea în care acestea pot fi selectate eficient.

Din punctul de vedere al unei companii, fie ea mică sau mare, utilitizând platforma WTC, compania își va putea defini viziunea și strategia pe termen lung, reducând considerabil cheltuielile neașteptate. Informația va fi scanată, etichetată, indexată și în final va avea o formă finală mai rafintă ași propune să vină în ajutorul a două categorii de participanți ai mediului de afaceri : pe de o parte companiile care au produse și informații de oferit, iar pe de altă parte clienții ce caută produse și informații. Problema ce intervine între cele două categorii este multitudinea de informații și modalitatea în care acestea pot fi selectate eficient.

Din punctul de vedere al unei companii, fie ea mică sau mare, utilitizând platforma WTC, compania își va putea defini viziunea și strategia pe termen lung, reducând considerabil cheltuielile neașteptate. Informația va fi scanată, etichetată, indexată și în final va avea o formă finală mai rafintă așteptată de toți clienții.

În calitate de utilizator final, folosind platforma WTC Lightweight, acesta va avea acces instant la o bază de date vastă și flexibilă. Informația este putere, ceea ce înseamnă că având date precise face diferența între un câștigător și un învins. Odată cu evoluția Internetului și cu Master Data Cloud-ul DCI-ului, fiecare viitor cumpărător din lume va avea acces nelimitat la cele mai noi date.

Utilizatorul va putea jongla cu produse specifice, portofolii ale companiilor, noutăți, elemente multimedia și campanii e-mail.

Astfel, putem afirma că WTC-ul este o soluție completă de business ce definește, administrează și promovează conținutul și identitatea companiei, mai exact: profilul, produsele și serviciile.

Platforma acoperă o varietate largă de procese și fluxuri de lucru dintre care enumerăm:

căutare, colectare, extragere și procesare de date relevante companiei provenind din surse diferite

Platforma este un portal pentru introducerea manuală de date sau a importării de date din surse specifice. Poate fi configurată și programată să conecteze și să extragă informații din WAi, RSS feeds și medii sociale.

distribuire și promovare de date legate de companie

O formă corectă ar fi să privim platforma ca pe un „business router”. Odată ce informația a fost stocată, ea va fi trimisă către canale profesionale, fie ele portale sau metaportale, infoboard-uri locale sau din toată lumea, editori de media sau portale mobile și aplicații.

scalabilitate

Făcând abstracție de cât de mare sau mică este afacerea, locală sau globală, platforma livrează informația optimă către grupurile și audiența țintă.

flexibilitate

Platforma este modulară, ceea ce înseamnă că numai serviciile și soluțiile de care are nevoie un anumit client vor fi proiectate și livrate.

securitate

Diferite nivele de acces și securitate sunt puse la dispoziție, cum ar fi acreditări pentru administratori / manageri de portal / manageri de content sau o selecție de acreditări pentru operatori sau parteneri. Ultimele tehnologii cloud sunt utilizate pentru a oferi o utilizare robustă și actualizată.

administrare inteligentă de documente

Platforma poate administra o multitudine de tipuri de date : ale utilizatorilor, companiilor, produse și soluții, newslettere și studii de caz. Pot fi definite obiecte customizate în funcție de nevoile clienților.

Cum funcționează sistemul ?

Din punct de vedere al unor deținători de content / manageri de portal :

Înregistrare cu contul de DCI : www.webtradecenter.com.

Automatizare procese de content. Când ceva este modificat în baza de date, toate instanțele conținutului vor fi actualizate automat.

Activare DCI Content Factory. Cu ajutorul acestuia se oferă acces la orice informație în orice format.

Se pot identifica instant nevoile particulare ale fiecărui partener de afaceri sau utilizator final. Mai departe se poate analiza profilul clientu bj\lui (industria, locația curentă, numărul de angajați, nevoile curente și viitoare).

Content-ul poate fi împărtășit cu toți operatorii de pe piață. Intern, cu ajutorul site-urilor proprii sau a sistemelor integrate, incluzând API-uri pentru sucursale, distribuitori, parteneri, agenții și furnizori, SAP și SalesForce.

Extern, cu toți partenerii de afaceri majori, incluzând, de exemplu : Amazon, IDG, Google, CeBIT sau eBay.

Monetizarea informației proprii. Se poate deține content, vinde, închiria sau sindicaliza, gratuit sau în schimbul unui cost specific.

În final, se integrează conectorul universal, oricărui produs sau serviciu, cu nicio limită de compatibilitate.

Din punct de vedere al unui partener de afaceri:

Înregistrare cu contul de DCI pe www.webtradecenter.com.

În calitate de partener autorizat, afiliat sau distribuitor, poți beneficia de o bază de date bine organizată ce conține content pus la dispoziție de către managerul de portal sau manegerul de content. Îți poți dezvolta propriul portal sau rețea internă, distribui și actualiza content.

Îmbunătățirea colaborării cu toți partenerii de afaceri și colaboratorii.

Din punct de vedere al unui utilizator final / consumator:

Cu ajutorul aplicației mobile WebTradeCenter Lightweight utilizatorul poate accesa date esențiale relației lui cu mediul de afaceri. Mai mult, acesta va putea selecta din ultimele informații, incluzând produse specifice, noutăți și fișiere multimedia. Va putea compara și cumpăra produsele mai ușor și mai rapid.

Alege și organizează punctele de interes favorite, după care WebTradeCenter va reține preferințele și va oferi mai departe numai informațiile de care are nevoie utilizatorul respectiv. Viitori cumpărători își pot crea o arie personală de „obiecte favorite” (accesând „Connections”), pot cere mai multe informații (accesând „Leads”) sau pot propune informații noi.

Servicii

Corporate Account

Acesta oferă servicii de bază ale platformei WebTradeCenter:

administrarea contentului

administrarea angajaților și a lanțurilor de aprovizionare

2.1.1. Înregistrare și apartenență

Orice partener de afaceri interesat de portalul WebTradeCenter trebuie să se înregistreze mai intâi.

Tipuri de înregistrări :

contul de WebTradeCenter;

conturi social media (Facebook, Twitter, LinkedIn, Google+);

autentificare personalizată bazată pe protocoale standard (de exemplu, SAML 2.0).

Odată înregistrat, un partener de afaceri poate să înceapă să construiască sau să revizuie o bază de date cu produse și companii. Se poate începe de la 0, sau DCI Content Factory poate identifica, aduna și procesa informațiile pentru utilizatorul respectiv.

Datele utilizatorului și content-ul țintă

Informațiile personale sunt folosite pentru a identifica piața țintă favorită a utilizatorului, ceea ce înseamnă că datele relevante pentru acea piață (produse, soluții, noutăți, portofolii ale companiilor) sunt afișate cu prioritate, iar interfața, opțiunile și mesajele sunt afișate în limba preferată de utilizator.

Datele companiei și regulile fluxului de lucru

Angajatorul / Managerul de Portal / Managerul de Content

compania de nivel superior a portalului

angajații lui pot fi fie membrii ai aceleiași companii, fie parteneri ce aparțin altor companii

el definește structura portalului, atribuie roluri și aprobă content

Angajații

participanți ai lanțului de aprovizionare cu content

operatori simpli ce editează date

parteneri de afaceri, comercianți autorizați, distribuitori

ei preiau datele din sistemul principal, adăugându-le apoi în canalele proprii

adaugă / actualizează content

Rețeaua de comercianți

deținătorul portalului își administrează rețeaua de comercianți

deținătorul de portal / managerul de content și principalii parteneri localizează furnizori, parteneri și comercianți

există comercianți ai unui producător care nu sunt deținătorii content-ului.

Funcția de Content Sharing : dacă un comerciant se înregistrează și este listat ca un partener autorizat al unui anumit producător, el moștenește descrierile produsului producătorului respectiv.

Compania

O companie este caracterizată în funcție de tip (producător, vânzător) , apartenență (Gold Partner, Platinum Partner, Channel Partner, Solution Partner), specificitate (Vertical Markets), piețele țintă (țări sau arii de interes).

Un portofoliu de companie include produsele și soluțiile publicate, noutățile acesteia sau pachete multimedia.

Content Management

Una dintre abilitățile de bază ale platformei WTC este capacitatea sa de a transforma tipuri diferite de content într-o bază de date organizată. DCI propune structuri standard de date, dar și structurile specifice pot fi definite de către operatorii platformei.

Câteva dintre abilitățile suportate de platformă ar fi :

procese pentru definirea regulilor de schimb de informații;

procese de delegare

editare, aprobare și publicare de capacități

Conexiuni

Există legături stabilite între utilizatori, companii și content. Conexiunile generează metadate care permit platformei să selecteze contentul potrivit unui anumit context. Astfel de tipuri de conexiuni sunt asocieri de content cu piețele lor regionale, vertical markets sau cu categorii de produse. Mai mult, există și tipuri de conexiuni adiționale care pot fi inițiate de către entități (utilizatori, companii) altele decât deținătorii contentului. De exemplu :

Favorites – marcaje adăugate de către utilizatori pentru a putea urmări content-uri și companii, pentru ca apoi utilizatorii să poată vedea un set complet de marcaje într-o secțiune specială a interfeței WebTradeCenter.

Store – conexiuni create de către companii care intenționează să promoveze produse și soluții ale altor companii în propriul portofoliu de produse.

Custom lists – utilizatorii își pot crea liste specifice cu ajutorul cărora să-și organizeze content-ul pe baza criteriilor proprii.

Content Dashboard

Acesta este o modalitate eficientă și sintetică de a vedea contentul pe care o companie îl are în sistem. Utilizatorii pot vizualiza o listă cu tot contentul lor, starea fiecărui content, informații adiționale relevante (categorii, piețe legate de content, număr de imagini, număr de documente atașate).

Figura . Content Dashboard

Activity Dashboard

Acesta reflectă activitatea utilizatorilor în cadrul platformei. Toate secțiunile pot fi monitorizate și controlate de către deținătorul portalului sau de managerul de content.

Această însușire este valabilă și pentru parteneri. Ei pot colecta date legate de întrebuințarea contentului, astfel că au o viziune mai relevantă asupra cererilor clienților.

Company Portal Service

Platforma WTC permite companiilor să creeze și administreze propriile portaluri. Acestea pot fi definite prin prisma a două „dimensiuni” : look and feel și content.

„Look and feel” : WTC permite companiilor să-și personalizeze înfățișarea portalului utilizând elemente proprii identității lor (culori, logo-uri, imagini).

Figura . Componentele unui portal WTC

Content : un portal de companie este structurat în jurul unei rețele de companii partenere afiliate deținătorului de portal și contentului pe care aceste companii îl aduc pe portal. În timp ce partenerii și contentul lor este substanța portalului, un deținător de portal poate personaliza elemente adiționale pentru a adapta portalul la tipul de afacere specific lui (vertical markets, product categories, key search criteria).

Figura . Rețea de companii

Structura portalului

Contentul fiecărui portal WTC este organizat astfel :

Companies

Solutions and Products

POS

Server Solutions

End-to-end Solutions

Vertical Markets

News

Connections

Figura . Structura unui portal WTC

Funcționalitatea de Search este un element esențial. Aceasta poate fi abordată prin prisma a 3 nivele:

primul conține criterii de căutare comune. Acestea nu sunt personalizabile per portal (cuvinte cheie, Vertical / Industry, Product Category, Membership Level, Badge, Company Partner).

al doilea conține criterii de căutare comune identificate pentru business. Acestea sunt personalizabile per portal.

al treilea conține atribute din sistem. Nu sunt personalizabile deoarece sunt returnate automat, în funcție de contentul disponibil.

Metaportalul companiei

O companie poate utiliza un singur portal sau un metaportal, ultimul caz presupunând suportarea unor subportaluri încorporate. În acest caz, fiecare subportal se comportă ca un portal de sine stătător, având propria structură, parteneri și content. Partenerii și contentul pot fi partajate între subportaluri multiple ale aceleiași companii, sau între portaluri independente.

Figura . Conceptul de meta-portal

Există două moduri în care ne putem raporta la un portal in WTC :

Companiile mai mari pot deține propriul nume de domeniu, de exemplu :

solutionfinder.intel.com.

Companiile mai mici care nu doresc să dețină propriul nume de domeniu pot opta pentru un folder virtual în WTC, cum ar fi: www.webtradecenter.com/aeonn.

În timp ce este logat în metaportal, un utilizator poate oscila între subportaluri sau se poate întoarce la portalul principal. Aceste opțiuni sunt disponibile cu ajutorul breadcrumb-ului.

Figura . BreadCrumb

Portal Dashboard

Este o metodă rapidă de monitorizare a stării contentului de pe portal. Astfel, deținătorul portalului poate verifica câte companii sunt înregistrate în prezent pe portal, câte produse au fost create, câte sunt în faza de așteptare (așteptând să fie aprobate sau publicate), câte produse au fost deja aprobate.

Figura . Portal Dashboard

Lead generation

Această funcționalitate pune la dispoziție posibiliatea de „Ask for more”.

Figura . Ask for more

Rapoarte și Statistici

Platforma deține funcționalități ce permit crearea de rapoarte personalizabile. Astfel, deținătorii de portal pot monitoriza activitatea, sarcinile si tendințele pe fiecare portal sau serviciu ce rulează. Modulul de Statistici este similar cu funcționalitățile oferite de Google Analytics. Acest lucru asigură, pe de o parte, o gamă largă de ustensile folositoare realizării rapoartelor, iar pe de altă parte nu limiteză compatibilitatea cu alte sisteme. Platforma pune la dispoziție rapoarte generice (ce acoperă valori populare utilizate de majoritatea clienților) dar și rapoarte specifice (adaptate la nevoile clientului).

Platforma poate fi programată să genereze și să transmită automat rapoartele dorite de audiență (prin e-mail sau alte canale de comunicare) sau pot fi declanșate manual de către clienți, la cerere și selectând diverși parametri.

Figura . Exemplu de raport și grafic

Câteva dintre rapoartele disponibile momentan:

contoare pentru vizualizarea activității de grup : sesiuni distincte, pagini relevante solicitate, pagini afișate, pagini din categoria de produse, pagini cu companii, pagini cu noutăți, etc.

folosirea criteriului de căutare : câte căutări au fost efectuate într-un interval specificat de timp, top 20 cele mai utilizate criterii de căutare, cel mai utilizat criteriu de căutare.

accesul la Content : top 100 cele mai vizualizate produse, top 100 cele mai vizualizate companii, top 100 cele mai vizualizate noutăți.

utilizarea datelor companiei : indicatori ce se referă la content-ul unei singure companii, pagini de companii vizualizate, produse ale companiei vizualizate.

instantanee : evoluția unor indicatori diverși de-a lungul timpului, produse active per companie, per categorie de produs, per verticals și categorir de produs, newslettere active per verticals.

evoluția în timp a numărului de infoboard-uri.

indicatori specifici : numărul de itemi de content per infoboard, numărul de active views, timpul de vizibilitate al unui infoboard.

Wide Area Infoboard (WAi)

Acest serviciu face posibiliă interacțiunea dintre utilizatori și produsele lor. Există doi actori principali implicați în acest serviciu : Publisher-ul și Advertiser-ul. Publisherul deține spațiu publicitar, iar Advertiserul furnizează contentul media ce va afișat în spațiul publicitar al Publisherului. Este posibil ca același corporate account să poată juca ambele roluri.

WAi-ul folosește Content Stream-uri și Infoboard-uri. Content Stream-urile sunt o modalitate eficientă prin care advertiserii și publisherii adaugă content în cadrul platformei. Adăugarea contentului pe platformă se face de obicei prin email.

Cele două funcționalități lucrează de obicei împreună, dar pot fi folosite și independent. Content Stream-urile pot fi folosite doar pentru a încărca portalul cu date. Pe de altă parte, un Inforboard poate fi configurat astfel încât să-și ia datele de la un Content Cluster fără să mai fie nevoie să folosească Content Stream-uri.

Figura . Mecanismul WAi

Campanii

Utilizând platforma, acest serviciu permite unui marketing team să definească grupuri țintă ce pot fi abordate cu ajutorul e+mailului sau a telefonului, scopul fiind indentificarea și dezvoltarea de marketing leads.

2.1.16 Online marketing

Platforma oferă clienților facilitatea de a expedia materiale promoționale către utilizatorii de internet. Există soluții diferite :

Newslettere : e-mailuri trimise către audiența țintă, pentru fiecare e-mail trimis, platforma ține evidența si obține statistici ale clickurilor fiecărui link din e-mail.

Cooperative emails : acest serviciu permite accounturilor care urmăresc aceleași piețe să se promoveze reciproc.

Infoboards : tipuri speciale de widgeturi ce afișează o secvență de itemi publicitari în diferite forme (tickere, slideuri). Pentru fiecare item publicitar, utilizatorul primește informații suplimentare într-un pop-over care este de fapt un active-view (este afișat atunci când utilizatorul poziționează mouseul pe el, mai multe informații fiind afișate dacă se face click).

Composite contents : tipuri standardizate de content. Contentul lor este compus din multiple „boxes of content”, fiecare content individual din cadrul platformei având un „box representation”.

Pentru a crea un amestec de contenturi, utilizatorul poate alege dintr-o gamă variată de cutii cu content :

Cutii cu propriul content – acestea conțin itemi noi și produse pe care acesta le deține în cont, sau cutii create pentru newslettere premium;

Cutiile altora, luate de pe peretele companiei sale;

Cutii asignate de către participanți ai e-mailurilor cooperative.

Figura . Conținut compus

Cap. 2. Serviciul WTC Collaborative Marketing

2.1 Atribuțiile unui Collaborative Marketer

Collaborative Marketer (Rol)

Este un corporate account ce pune la dispoziție serviciul de Collaborative Marketing.

Atribuțiile sale sunt:

Administrarea adreselor de email (Activitate)

Orice partener care folosește acest serviciu va trebui să administreze adresele de email pe care le aduce de-a lungul procesului de colaborare. Partenerul va fi capabil să selecteze ce adrese vrea să includă în fiecare grup de colaborare din care face parte.

(Interfață ce permite importarea adreselor de email dintr-un fișier xls).

Creare de grupuri de colaborare (Activitate)

Grupurile de colaborare sunt asocieri între parteneri care își vor distribui listele cu destinatari pentru a se promova, totul având la bază principiul reciprocității.

Orice partener poate crea grupuri de colaborare. Un partener își poate crea propriul grup sau poate adera la grupuri create de alți parteneri. Un grup poate fi privat, detectabil sau public. Un grup privat este un grup creat și operat de către deținător, nefiind detectabil. Ceilalți parteneri pot fi invitați doar de către deținător.

Un grup detectabil poate fi căutat de către alți parteneri care pot adera la el. Faptul că grupul este detectabil nu garantează că partenerii vor deveni automat membrii ai acestuia, dar au șansa să aplice urmând ca deținătorul grupului respectiv decidă dacă îi va accepta sau nu.

Șeful grupului poate stabili anumiți parametri, cum ar fi numărul minim de adrese de email pe care un membru trebuie să le adauge la grup pentru a putea deveni membru.

Fiecare grup va avea un “Alive Index” care va reflecta dinamica acestuia, numărul de membri, numărul total de destinatari, numărul de Ad Boxes și Newslettere generate în cadrul grupului. Owner-ul decide dacă “Alive Index-ul” este vizibil pentru grupurile detectabile sau nu.

Grupul va avea parametrii “cotă” pentru a putea elimina potențialele abuzuri. Aceștia ar fi:

numărul maxim de newslettere ce pot fi inițiate de fiecare membru pe săptămână

interval de diminuare pentru newslettere ulterioare în cadrul aceluiași grup

interval de diminuare pentru newslettere ulterioare ale aceluiași membru

Căutare și aplicare la grupuri de colaborare

Partenerii își pot crea propriile grupuri sau pot căuta grupuri existente la care să adere. Aplicația conține următoarele informații:

Numărul de adrese de email pe care partenerul solicitant le va aduce în grup (> 100, > 1000, > 3000, > 5000, > 10000)

Un profil descriptiv al destinatarilor aduși în grup de către solicitant

Ceilalți membrii ai grupului nu vor avea acces la listele cu email-uri aduse de către un partener, ele rămân confidențiale. Când un partener aplică la un grup colaborativ o solicitare este trimisă deținătorului grupului și acesta o aprobă după ce o vizualizează.

Această activitate mai presupune și pregătirea unui subset de contacte ce vor fi distribuite distribuite într-un grup. Subseturile de contacte pot fi atribuite mai multor grupuri simultan, dar numărul de contacte dintr-un grup de contacte nu poate fi mai mic decât numărul de contacte communicate aplicației. Platforma utilizează procese de validare a email-ului, astfel că numai adresele de contact valide vor fi adăugate subseturilor.

Revizualizarea și confirmarea solicitărilor pentru grupurile deținute

Administratorul grupului va fi notificat când un partener aplică la grupul său, astfel că deținătorul revizualizează solicitarea și o acceptă sau respinge. Solicitantul este înștiințat în ambele cazuri, mesajul conținând și o motivație a manager-ului pentru decizia sa.

Administrare de Ad Box-uri

Ad Box-urile sunt administrate de către partener independent de serviciul Collaborative Marketing. Dacă partenerul are serviciul activat el va avea acces la un ecran special unde își va putea organiza și prioritiza Ad Box-urile pe care dorește să le utilizeze în campaniile de email.

Creare de newslettere colaborative

Orice membru al grupului poate crea un newsletter colaborativ, respectând parametrii impuși pentru grupul respectiv. Când un newsletter colaborativ este creat, creatorul acestuia va selecta Ad Box-uri din ansamblul de Ad Box-uri ale membrilor.

Platforma recomandă Ad Box-uri pe baza următoarelor criterii :

priorități recomandate de către owner-ul Ad Box-ului

ultima oară când au fost distribuite Ad Box-uri

performanța fiecărui Ad Box

rata de echitate a fiecărui creator de newslettere față de partenerii Ad Box ( este recomandat ca în cazul în care un partener folosește des Ad Box-ul altui partener cel din urmă să facă la fel, pentru a se respecta principiul reciprocității; rata echității ia mai multe elemente în calcul, nu numai numărul de Ad Box-uri incluse în email dar și numărul de destinatari pe care fiecare partener îi aduce în grup sau numărul de click-uri pe care un Ad Box l-a obținut în cadrul unui email de aparține altui partener).

Revizualizarea performanței newsletterelor colaborative

Figura . Owner Matching

2.2 Descrierea rapoartelor și a indicatorilor

Pentru a cunoaște situația unui anumit cont, următoarele tipuri de rapoarte trebuiesc făcute disponibile:

Ad Box performance report

Acest raport prezintă situația Ad Box-urilor folosite de membrii grupurilor într-un anumit interval de timp. Se folosesc următorii indicatori :

De câte ori a fost inclus fiecare Ad Box într-un Newsletter deținut;

De câte ori a fost inclus fiecare Ad Box în Newsletterle altor parteneri;

Către ce număr de destinatari de email a fost livrat un Ad Box – destinatari proprii;

Către ce număr de destinatari de email a fost livrat un Ad Box – destinatari aparținând partenerilor;

Către ce număr de destinatari distincți a fost livrat un Ad Box – destinatari proprii;

Către ce număr de destinatari distincți a fost livrat un Ad Box – destinatari aparținând partenerilor;

De câte ori a fost deschis un Newsletter conținând Ad Box-ul respectiv dintr-un email aparținând partenerilor proprii;

De câte ori a fost deschis un Newsletter conținând Ad Box-ul respectiv dintr-un email aparținând altor parteneri;

Câte Active View-uri a obținut un Ad Box în total din email-uri ce aparțin destinatarilor proprii;

Câte Active View-uri a obținut un Ad Box în total din email-uri ce aparțin destinatarilor altor parteneri;

De câte ori a fost deschis un Newsletter conținând Ad Box-ul respectiv în portaluri WTC – newslettere proprii

De câte ori a fost deschis un Newsletter conținând Ad Box-ul respectiv în portaluri WTC – newsletterele partenerilor

Câte Active Viewuri a obținut un Ad Box afișat în portaluri WTC.

Report Data Model

Modelul de date al acestui raport include :

Newsletter performance report

Acest raport prezintă situația Newsletterelor folosite de membrii grupurilor într-un anumit interval de timp. Se folosesc următorii indicatori :

De câte ori a fost deschis un Newsletter de către un destinatar de email propriu;

De câte ori a fost deschis un Newsletter de către un destinatar de email aparținând unui partener

De câte ori a fost deschis un Newsletter din portaluri WTC (inbox-uri, liste)

Câte Active View-uri proprii au fost generate de către Newsletterul respectiv

Câte Active View-uri proprii au fost generate de către Newsletterul respectiv – utilizatori distincți

Câte Active View-uri aparținând partenerilor au fost generate de către Newsletterul respectiv

Câte Active View-uri aparținând partenerilor au fost generate de către Newsletterul respectiv – utilizatori distincți

Report Data Model

Modelul de date al acestui raport include :

Collaborative Group Report

Acest raport prezintă situația grupurilor într-un anumit interval de timp. Se folosesc următorii indicatori :

Numărul de Ad Box-uri inclus în Newslettere de către fiecare membru al grupului

Numărul de Newslettere create în grup de către fiecare partener

Numărul de Newslettere create de către partener care includ Ad Box-uri aparținând membrului respectiv

Numărul de contacte aduse de către partener în grupul colaborativ

Numărul de contacte aduse de către partener și atinse de către Newsletterele membrului respectiv

Numărul de Active View-uri pe Ad Box-uri, produse de către contactele partenerilor

Report Data Model

Modelul de date al acestui raport include :

2.3 Descrierea aplicației

Pentru a face posibilă crearea si afișarea acestor rapoarte avem nevoie în primul rând de o bază de date unde să stocăm toate informațiile necesare. Aceasta este creată utilizând abordarea Entity Framework – Code First, ceea ce înseamnă că mai întâi creăm un class library unde ne definim modelul și o aplicație de tip consolă a cărui rulare va avea consecința de a crea baza de date în SQL Server Management Studio.

Baza de date este numită WTC_COLMK, drept urmare class library-ul poartă aceeași denumire. Pentru raportul despre performanța Ad Box-urilor am creat următoarele clase care servesc drept model :

public class AdBox

{

[DatabaseGenerated(DatabaseGeneratedOption.Identity)]

public int Id {get;set;}

public int AdBoxId { get; set; }

public virtual AdBoxData AdBoxData { get; set; }

public int IndicatorId { get; set; }

public virtual AdBoxIndicator AdBoxIndicator { get; set; }

public DateTime Date { get; set; }

public AdBox(int adBoxId, int indicatorId, DateTime date)

{

this.AdBoxId = adBoxId;

this.IndicatorId = indicatorId;

this.Date = date;

}

public AdBox() { }

}

Această clasă conține toate datele necesare creării raportului.

public class AdBoxIndicator

{

public int Id { get; set; }

public string IndicatorName { get; set; }

public virtual ICollection<AdBox> AdBoxes { get; set; }

public AdBoxIndicator(int indicatorId, string indicatorName)

{

this.Id = indicatorId;

this.IndicatorName = indicatorName;

}

public AdBoxIndicator() { }

}

Clasa AdBoxIndicator conține toți indicatorii unui raport, iar clasa AdBoxData conține date despre Id-ul și numele Ad Box-urilor respective.

public class AdBoxData

{

public int Id { get; set; }

public string AdBoxName { get; set; }

public virtual ICollection<AdBox> AdBoxes { get; set; }

public AdBoxData(int adBoxId, string adBoxName)

{

this.Id = adBoxId;

this.AdBoxName = adBoxName;

}

public AdBoxData() { }

}

Pentru raportul despre performanța Newsletterelor situația este asemănătoare.

public class Newsletter

{

[DatabaseGenerated(DatabaseGeneratedOption.Identity)]

public int Id { get; set; }

public int NewsletterId { get; set; }

public virtual NewsletterData NewsletterData { get; set; }

public int IndicatorId { get; set; }

public virtual NewsletterIndicator NewsletterIndicator { get; set; }

public DateTime Date { get; set; }

public Newsletter(int newsletterId, int indicatorId, DateTime date)

{

this.NewsletterId = newsletterId;

this.IndicatorId = indicatorId;

this.Date = date;

}

public Newsletter() { }

}

public class NewsletterData

{

public int Id { get; set; }

public string NewsletterName { get; set; }

public virtual ICollection<Newsletter> Newsletters { get; set; }

public NewsletterData(int newsletterId, string newsletterName)

{

this.Id = newsletterId;

this.NewsletterName = newsletterName;

}

public NewsletterData() { }

}

public class NewsletterIndicator

{

public int Id { get; set; }

public string IndicatorName { get; set; }

public virtual ICollection<Newsletter> Newsletters { get; set; }

public NewsletterIndicator(int indicatorId, string indicatorName)

{

this.Id = indicatorId;

this.IndicatorName = indicatorName;

}

public NewsletterIndicator() { }

}

În cazul raportului pentru grupurile colaborative situația este puțin diferită deoarece trebuie să adăugăm și tabela cu membrii grupurilor.

[DatabaseGenerated(DatabaseGeneratedOption.Identity)]

public int Id { get; set; }

public int CollaborativeGroupId { get; set; }

public virtual CollaborativeGroupData CollaborativeGroupData { get; set; }

public int IndicatorId { get; set; }

public virtual CollaborativeGroupIndicator CollaborativeGroupIndicator { get; set; }

public int MemberId { get; set; }

public virtual CollaborativeGroupMember CollaborativeGroupMember { get; set; }

public DateTime Date { get; set; }

public CollaborativeGroup(int collaborativeGroupId, int indicatorId, int memberId, DateTime date)

{

this.CollaborativeGroupId = collaborativeGroupId;

this.IndicatorId = indicatorId;

this.MemberId = memberId;

this.Date = date;

}

public CollaborativeGroup() { }

}

public class CollaborativeGroupData

{

public int Id { get; set; }

public string CollaborativeGroupName { get; set; }

public virtual ICollection<CollaborativeGroup> CollaborativeGroups { get; set; }

public CollaborativeGroupData(int collaborativeGroupId, string collaborativeGroupName)

{

this.Id = collaborativeGroupId;

this.CollaborativeGroupName = collaborativeGroupName;

}

public CollaborativeGroupData() { }

}

public class CollaborativeGroupIndicator

{

public int Id { get; set; }

public string IndicatorName { get; set; }

public virtual ICollection<CollaborativeGroup> CollaborativeGroups { get; set; }

public CollaborativeGroupIndicator(int indicatorId, string indicatorName)

{

this.Id = indicatorId;

this.IndicatorName = indicatorName;

}

public CollaborativeGroupIndicator() { }

}

public class CollaborativeGroupMember

{

public int Id { get; set; }

public string MemberName { get; set; }

public virtual ICollection<CollaborativeGroup> CollaborativeGroups { get; set; }

public CollaborativeGroupMember(int memberId, string memberName)

{

this.Id = memberId;

this.MemberName = memberName;

}

public CollaborativeGroupMember() { }

Crearea relațiilor dintre tabele este definită în clasa WTC_COLMKServiceContext derivată din DbContext. Folosim DbSet pentru a seta entitățile, după care cu ajutorul Fluent API, în interiorul metodei OnModelCreating, definim relațiile dintre entități.

public class WTC_COLMKServiceContext : DbContext

{

public DbSet<AdBoxIndicator> AdBoxIndicators { get; set; }

public DbSet<AdBox> AdBoxes { get; set; }

public DbSet<AdBoxData> AdBoxDatas { get; set; }

public DbSet<CollaborativeGroupIndicator> CollaborativeGroupIndicators { get; set; }

public DbSet<CollaborativeGroupMember> CollaborativeGroupMembers { get; set; }

public DbSet<CollaborativeGroup> CollaborativeGroups { get; set; }

public DbSet<CollaborativeGroupData> CollaborativeGroupDatas { get; set; }

public DbSet<NewsletterIndicator> NewsletterIndicators { get; set; }

public DbSet<Newsletter> Newsletters { get; set; }

public DbSet<NewsletterData> NewsletterDatas { get; set; }

public WTC_COLMKServiceContext()

: base("WTC_COLMK")

{ }

protected override void OnModelCreating(DbModelBuilder modelBuilder)

{

// AdBoxDataContext

modelBuilder.Entity<AdBox>()

.HasRequired(a => a.AdBoxData)

.WithMany(i => i.AdBoxes)

.HasForeignKey(a => a.AdBoxId);

modelBuilder.Entity<AdBox>()

.HasRequired(a => a.AdBoxIndicator)

.WithMany(i => i.AdBoxes)

.HasForeignKey(a => a.IndicatorId);

// CollaborativeGroupDataContext

modelBuilder.Entity<CollaborativeGroup>()

.HasRequired(c => c.CollaborativeGroupData)

.WithMany(g => g.CollaborativeGroups)

.HasForeignKey(c => c.CollaborativeGroupId);

modelBuilder.Entity<CollaborativeGroup>()

.HasRequired(c => c.CollaborativeGroupIndicator)

.WithMany(i => i.CollaborativeGroups)

.HasForeignKey(c => c.IndicatorId);

modelBuilder.Entity<CollaborativeGroup>()

.HasRequired(c => c.CollaborativeGroupMember)

.WithMany(m => m.CollaborativeGroups)

.HasForeignKey(c => c.MemberId);

// NewsletterDataContext

modelBuilder.Entity<Newsletter>()

.HasRequired(n => n.NewsletterData)

.WithMany(i => i.Newsletters)

.HasForeignKey(n => n.NewsletterId);

modelBuilder.Entity<Newsletter>()

.HasRequired(n => n.NewsletterIndicator)

.WithMany(i => i.Newsletters)

.HasForeignKey(n => n.IndicatorId);

base.OnModelCreating(modelBuilder);

}

}

Pentru a popula baza de date folosim metoda Seed în clasa DropCreateDBWithSeedData iar în programul din aplicația de tip consolă instanțiem clasa context.

using (var ctx = new WTC_COLMKServiceContext())

{

new DropCreateDBWithSeedData().InitializeDatabase(ctx);

}

Tabelele sunt create în SQL Server Management Studio iar următorul pas este crearea unui class library denumit ReportLibraryService care va servi drept ObjectDataSource pentru crearea raportului în Report Designer. Deoarece în aplicația WTC_COLMK am definit doar câmpurile esențiale unei baze de date care să simuleze time tracking-ul, în ReportLibraryService vom adăuga câmpuri adiționale necesare creării raportului, acestea fiind rezultatul acțiunilor din baza de date.

După ce creăm clasele model în care vom prelua datele din baza de date pentru a le transmite Report Designer-ului, creăm metodele care extrag datele, astfel :

[System.ComponentModel.DataObjectMethod(System.ComponentModel.DataObjectMethodType.Select)]

public List<AdBoxSerieDataModel> GetAdBoxData()

{

List<AdBoxSerieDataModel> model = new List<AdBoxSerieDataModel>();

var connectionString = "Data Source=LD\\LAURAPC;Initial Catalog=WTC_COLMK;Integrated Security=true;";

using (SqlConnection sqlc = new SqlConnection(connectionString))

{

SqlCommand cmd = new SqlCommand("SELECT COUNT(*) as SerieValue, AdBoxId, AdBoxName, IndicatorId, IndicatorName, DATENAME(MONTH, Date) + ' ' + CAST(YEAR(Date) AS VARCHAR(4)) AS SerieLabel FROM [WTC_COLMK].[dbo].[AdBoxes], [WTC_COLMK].[dbo].[AdBoxIndicators], [WTC_COLMK].[dbo].[AdBoxDatas] WHERE AdBoxes.IndicatorId = AdBoxIndicators.Id AND AdBoxes.AdBoxId = AdBoxDatas.Id GROUP BY DATENAME(MONTH, Date) + ' ' + CAST(YEAR(Date) AS VARCHAR(4)), AdBoxId, AdBoxName, IndicatorId, IndicatorName order by IndicatorId", sqlc);

cmd.Connection = sqlc;

sqlc.Open();

SqlDataReader dr = cmd.ExecuteReader();

Console.WriteLine("AD BOXES : ");

while (dr.Read())

{

AdBoxSerieDataModel adS = new AdBoxSerieDataModel()

{

IndicatorId = int.Parse(dr["IndicatorId"].ToString()),

IndicatorName = dr["IndicatorName"].ToString(),

Date = DateTime.Parse(dr["SerieLabel"].ToString()),

Value = int.Parse(dr["SerieValue"].ToString()),

AdBoxId = int.Parse(dr["AdBoxId"].ToString()),

AdBoxName = dr["AdBoxName"].ToString()

};

model.Add(adS);

Console.WriteLine(adS.AdBoxId + " " + adS.AdBoxName + " " + adS.IndicatorName + " " + adS.Month + " " + adS.Value);

}

sqlc.Close();

return model;

}

}

[System.ComponentModel.DataObjectMethod(System.ComponentModel.DataObjectMethodType.Select)]

public List<NewsletterSerieDataModel> GetNewsletterData()

{

List<NewsletterSerieDataModel> model = new List<NewsletterSerieDataModel>();

var connectionString = "Data Source=LD\\LAURAPC;Initial Catalog=WTC_COLMK;Integrated Security=true;";

using (SqlConnection sqlc = new SqlConnection(connectionString))

{

SqlCommand cmd = new SqlCommand(" SELECT COUNT(*) as SerieValue, NewsletterId, NewsletterName, IndicatorId, IndicatorName, DATENAME(MONTH, Date) + ' ' + CAST(YEAR(Date) AS VARCHAR(4)) AS SerieLabel FROM [WTC_COLMK].[dbo].[Newsletters], [WTC_COLMK].[dbo].[NewsletterIndicators], [WTC_COLMK].[dbo].[NewsletterDatas] WHERE Newsletters.IndicatorId = NewsletterIndicators.Id AND Newsletters.NewsletterId = NewsletterDatas.Id GROUP BY DATENAME(MONTH, Date) + ' ' + CAST(YEAR(Date) AS VARCHAR(4)), NewsletterId, NewsletterName, IndicatorId, IndicatorName order by IndicatorId;", sqlc);

cmd.Connection = sqlc;

//cmd.CommandText = sql;

sqlc.Open();

SqlDataReader dr = cmd.ExecuteReader();

Console.WriteLine("NEWSLETTERS : ");

while (dr.Read())

{

NewsletterSerieDataModel nwS = new NewsletterSerieDataModel()

{

IndicatorId = int.Parse(dr["IndicatorId"].ToString()),

IndicatorName = dr["IndicatorName"].ToString(),

Date = DateTime.Parse(dr["SerieLabel"].ToString()),

Value = int.Parse(dr["SerieValue"].ToString()),

NewsletterId = int.Parse(dr["NewsletterId"].ToString()),

NewsletterName = dr["NewsletterName"].ToString()

};

model.Add(nwS);

Console.WriteLine(nwS.NewsletterId + " " + nwS.NewsletterName + " " + nwS.IndicatorName + " " + nwS.Month + " " + nwS.Value);

}

sqlc.Close();

return model;

}

}

[System.ComponentModel.DataObjectMethod(System.ComponentModel.DataObjectMethodType.Select)]

public List<CGSerieDataModel> GetMemberData() {

List<CGSerieDataModel> model = new List<CGSerieDataModel>();

var connectionString = "Data Source=LD\\LAURAPC;Initial Catalog=WTC_COLMK;Integrated Security=true;";

using (SqlConnection sqlc = new SqlConnection(connectionString))

{

SqlCommand cmd = new SqlCommand("SELECT CollaborativeGroupId, CollaborativeGroupName, IndicatorId, IndicatorName, MemberId, MemberName, Date FROM CollaborativeGroups, CollaborativeGroupIndicators, CollaborativeGroupDatas, CollaborativeGroupMembers WHERE CollaborativeGroups.IndicatorId = CollaborativeGroupIndicators.Id AND CollaborativeGroups.CollaborativeGroupId = CollaborativeGroupDatas.Id AND CollaborativeGroups.MemberId = CollaborativeGroupMembers.Id;", sqlc);

cmd.Connection = sqlc;

//cmd.CommandText = sql;

sqlc.Open();

SqlDataReader dr = cmd.ExecuteReader();

Console.WriteLine("COLLABORATIVE GROUPS : ");

while (dr.Read())

{

CGSerieDataModel cgS = new CGSerieDataModel()

{

CollaborativeGroupId = int.Parse(dr["CollaborativeGroupId"].ToString()),

CollaborativeGroupName = dr["CollaborativeGroupName"].ToString(),

IndicatorId = int.Parse(dr["IndicatorId"].ToString()),

IndicatorName = dr["IndicatorName"].ToString(),

MemberId = int.Parse(dr["MemberId"].ToString()),

MemberName = dr["MemberName"].ToString(),

Date = DateTime.Parse(dr["Date"].ToString()),

Value = GetSerieValue(10, 1000),

};

model.Add(cgS);

Console.WriteLine(cgS.CollaborativeGroupId + " " + cgS.IndicatorId + " " + cgS.MemberId + " " + cgS.Month + " " + cgS.Value);

}

sqlc.Close();

return model;

}

}

Observăm că datele sunt returnate cu ajutorul unor interogări. În Designer datele sunt puse într-un tabel, grupând după numele indicatorului și după dată, la fel procedând și în cazul realizării graficelor.

Cap. 3. Tehnologiile folosite în realizarea aplicației

3.1. Limbajul C#

Limbajul de programare C# poate fi folosit pentru crearea mai multor tipuri de aplicații, cum ar fi site-uri web, aplicații desktop, jocuri, aplicații mobile. Unul dintre cele mai esențiale avantaje ale acestui limbaj este gama largă de tehnici de programare pe care le suportă, din care putem enumera funcționalitățile de programare orientată pe obiect, programarea funcțională, funcțonalități orientate pe liste și set-uri mulțumită LINQ. Recent a fost adăugat suport și pentru programarea asincronă.

C# este considerat ca făcând parte din familia C a limbajelor de programare. Acesta este un limbaj de programare foarte influențator și multe alte limbaje au împrumutat din sintaxa lui. Chiar și Java, care este destul de îndepărtat și nu este compatibil cu el conține câteva aspecte definitorii ale sintaxei C. Revenind la C# și la structura acestuia, codul este format din statement-uri plasate în interiorul unei metode, aceasta din urmă aparținând unui anumit tip, la rândul său acesta fiind în interiorul unui namespace, toate acestea făcând parte dintr-un proiect Visual Studio.

Variabilele ne permit să definim informația cu care codul nostru lucrează, dar pentru a putea face ceva cu acestea trebuie să scriem cod, ceea ce înseamnă statement-uri și expresii. Când scriem o metodă C#, scriem o secvență de statement-uri. Acestea descriu acțiunile pe care vrem ca metoda noastră să le execute. C# recunoaște mai multe tipuri de statement-uri, cum ar fi, statement-uri de declarare, când scriem un loop, putem spune că scriem un statement de iterare. Când folosim mecanisme precum if sau select pentru a alege între posibile acțiuni, folosim statement-uri de selecție.

Definiția oficială a unei expresii C# este mai degrabă seacă: “o secvență de operatori și operanzi”. O altă încercare de a descrie o expresie este aceea de a spune că este un cod care produce o valoare. Cea din urmă nu este adevărate pentru toate expresiile, dar majoritatea se vor potrivi descrierii acesteia, depinzând, bineînțeles, și de context. Cele mai simple expresii cu valori sunt literalii, unde doar definim valorile pe care le dorim.

Când se pune problema tipurilor de date, platforma .NET definește mii de tipuri de date în class library-ul ei, dar programatorul își poate scrie propriile tipuri de date, astfel că se poate lucra cu un număr nelimitat de tipuri de date.

Tipurile de date numerice se împart în Integer și Floating Point. Dintre tipurile Integer putem enumera : byte, sbyte, ushort, short, uint, int, ulong, long. Tipurile Floating Point sunt float și double. Există și o a treia reprezentare pe care C# o recunoaște, numită decimal sau System.Decimal în .NET. Tipul decimal este mai eficient deoarece oferă o precizie mai bună a numărului de zecimale. Ultimul tip de date numeric este BigInteger, introdus în .NET 4.0 . După cum sugerează și numele, un BigInteger reprezintă un Integer, unicitatea lui constând în faptul că poate crește cât de mult este necesar pentru a se putea acomodata cu valorile resprective. Pnetru a-l putea folosi trebuie să face referire la namespace-ul System.Numerics deoarece este într-un DLL separat pentru care Visual Studio nu face referință implicit.

Booleeni oferă două tipuri de date, true și false. Tipul de date string reprezintă o secvență de caractere text, fiecare caracter din secvență fiind de tipul char.

Ultimul tip de date intrinsec este Object, acesta fiind și clasa de bază pentru toate tipurile C#. O variabilă de tip object este capabilă să facă referire la o valoare de orice tip care derivă din object.

Entity Framework – Code First

Pentru a putea înțelege ce presupune abordarea Code First trebuie să înțelegem în primul rând conceptul Entity Framework. Definiția dată de cei de la Microsoft spune că Microsoft ADO.NET Entity Framework este o platformă de lucru ORM care le permite programatorilor să lucreze cu date relaționale eliminând nevoia de a scrie cod pentru accesarea datelor. Utilizând acest instrument, programatorii pot crea interogări folosind LINQ, urmând ca datele să poată fi manipulate în funcție de cerințe. Mai exact, Entity Framework oferă programatorilor un mecanism automat pentru accesarea și stocarea datelor în baza de date. Există trei scenarii în care instrumentul ne poate fi de folos. Primul presupune faptul că avem deja o bază de date existentă sau vrem să prelucrăm mai întâi baza de date și apoi celelalte părți ale aplicației. Al doilea scenariu prezintă situația în care dorim să ne concentrăm atenția asupra claselor principale și apoi creăm baza de date pe baza acestora. Al treilea presupune că vrem să ne creăm mai întâi schema bazei de date folosind un designer vizual după care creăm baza de date și clasele.

Figura Scenarii Entity Framework

În cazul în care suntem nesiguri în legătură cu alegerea modului în care vrem să lucrăm cu Entity Framework, următoare figură ne vine în ajutor.

Figura Arbore de decizie EF

Concentrându-ne atenția asupra abordării Code First, lucrul se începe cu scrierea claselor în C# sau Visual Basic. Când compilăm aplicația, API-urile Code First creează noua bază de date și mapează clasele la baza de date folosind convențiile implicite. Este de asemenea posibil să configurăm clasele astfel încât acestea să suprascrie convențiile implicite cu tabele bazei de date folosind atribute DataAnnotation sau Fluent API.

O convenție în termeni de programare este un set de reguli cu ajutorul cărora se configurează un model conceptual automat, bazându-se pe definițiile claselor de domeniu. Nu putem vorbi însă despre atribute DataAnnotation și Fluent API fără să amintim de clasa DbContext, care este o parte esențială a conceptului Entity Framework. Aceasta acționează ca o punte între entitățile definite de noi și baza de date.

Figura . DbContext

DbContext este clasa primară responsabilă pentru interacțiunea cu datele ca obiect, având următorele sarcini :

Entity Set : DbContext conține setare de entități (DbSet<TEntity>) pentru toate entitățile la care este mapat către tabelele bazei de date;

Interogare : DbContext convertește interogările LINQ-to-Entities la interogări SQL și le trimite către baza de date;

Change Tracking : păstrează toate schimbările care au intervenit asupra entităților după ce au fost interogate din baza de date;

Date persistente : efectuează operații de Insert, Update și Delete asupra bazei de date;

Caching : DbContext stochează entitățile care au fost returnate de’a lungul ciclul de viață a unei clase context.

Putem folosi DbContext instanțiind clasa context și pentru a efectua operații CRUD.

using (var ctx = new WTC_COLMKServiceContext())

{

// operații CRUD

}

Clasa DBSet reprezintă un set de entități folosite pentru operații CRUD. Este inclusă în clasa DbContext.

Revenind la atribute, despre DataAnnotation putem spune că oferă doar un subset de opțiuni pentru configurarea modelului, pe când Fluent API oferă un set complet. System.ComponentModel.DataAnnotations include atribute care au impact asupra mărimii și nulității coloanei. Exemple : Key, TimeStamp, ConcurrencyCheck, Required, MinLength, MaxLength, StringLength.

System.ComponentModel.DataAnnotations.Schema conține atribute care afectează schema bazei de date, exemple fiind : Table, Column, Index, ForeignKey.

În cazul Fluent API, trebuie să începem prin a specifica cea mai importantă clasă, și anume EntityTypeConfiguration, care pune la dispoziție metode cu ajutorul cărora se pot configura entități plus proprietățile care suprascriu convenții Code First variate. Poate fi obținută invocând metoda Entity<TEntity>() din clasa DbModelBuilder. Cele mai importante metode din clasa EntityTypeConfiguration sunt : HasKey<TKey>, HasMany<TTargetEntity>, HasOptional<TTargetEntity>, HasRequired< TTargetEntity>.

Mai departe trebuie să amintim depsre strategii de inițializare a bazei de date deoarece trebuie să știm care este cea mai potrivită în funcție de acțiunile pe care vrem să le efectuăm asupra acesteia. Adtfel, există 4 strategii :

CreateDatabaseIfNotExists : inițializatorul implicit. Creează baza de date dacă nu există încă;

DropCreateDatabaseIfModelChanges : inițializatorul șterge baza de date existentă și creează una nouă, dacă modelul s-a schimbat;

DropCreateDatabaseAlways : inițializatorul șterge baza de date existentă de fiecare dată când rulăm aplicația;

Custom DB Initializer : ne putem crea propriul inițializator dacă niciuna din situațiile de mai sus nu se potrivește scenariului nostru.

SQL Server Management Studio

Microsoft SQL Server este un sistem pentru gestiunea bazelor de date care folosește un limbaj structurat de interogare (SQL – Structured Query Language), acesta fiind unul dintre ele mai populare limabje folosite pentru manipularea datelor (creare, modificare, regăsire). Standardul SQL este bazat pe modelul relațional, model creat de către Edgar F. Codd în 1969, iar SQL apare în anul 1974 sub denumirea de SEQUEL.

Despre limbajul SQL trebuie să mai menționăm că este un limbaj declarativ și are două părți, una logică și una fizică. Prima reprezintă interpretarea interogărilor, iar a doua procesarea acestora.

Ordinea de scriere a clauzelor este următoarea : SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, iar procesarea interogării se face astfel : FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY.

SQL Server Management Studio este un mediu integrat pentru accesarea, configurarea, administrarea și dezvoltarea tuturor componentelor SQL Server. Acesta folosește o gamă largă de servicii grafice cu un număr mare de editoare de script pentru a conferi acces la SQL Server programatorilor și administratorilor.

SSMS combină funcționalități precum Enterprise Manager, Query Analyzer și Analysis Manager într-un singur mediu, funcționalități la care se adaugă și serviciile de raportare și integrare.

Figura Sql Server Management Studio

Telerik Reporting Q1 2015

Telerik Reporting este un mediu în care se pot crea rapoarte pentru platformele .NET cloud, web și desktop care oferă o gamă largă de instrumente și servicii care ajută la crearea, lansarea și utilizarea rapidă a rapoartelor. Cu Telerik Reporting, se pot returna date din medii relaționale, multidimensionale, ORM sau surse de date personalizate. Rapoartele pot fi vizualizate în diferite formate (PDF, Microsoft Office Word, Excel, PowerPoint), dar și în aplicații web sau desktop, iar crearea lor se poate face în Visual Studio Report Designer sau în Standalone Report Designer. Cel din urmă permite autorilor de rapoare să le creeze, editeze și distribuie. Este un singur fișier exe, ceea ce îi simplifică distribuirea și nu necesită instalare. Nu are nevoie de Visual Studio pentru a putea funcționa deoarece rapoartele sunt procesate pe mașina client.

Elemente:

View Tab : permite deschiderea Report Explorer-ului, Data Explorer-ului, Group Explorer-ului și a Property Browser-ului sau navigarea pe pagina de Start;

Figura. View Tab

Report selector button : este localizat în parte de stânga sus a designer-ului. Apăsarea acestui buton va face raportul activ în fereastra Properties;

Rulers : localizați în partea de sus și stanga a designer-ului, oferă un punct de referință pentru înfățișarea raportului;

Report Sections : există secțiuni pentru header-ul raportului, footer, header-ul paginii, footer-ul paginii, detalii, header-ul și footer-ul unui anumit grup. Fiecare secțiuni poate fi redimensionată trăgând de colțurile fiecăreia. Majoritatea secțiunilor, exceptând-o pe cea de detalii, pot fi șterse. Pentru a șterge o secțiune cu grupuri, trebuie șters întregul grup din Group Explorer.

Component Tray : afișează componentele DataSource utilizate în raportul respectiv.

Context Menu : acest meniu va afișa condiționat informații depinzând de spațiul care a fost selectat prin click.

View Mode Buttons : aceste butoane sunt folosite pentru comutarea între Design și Preview.

Zoom selector : meniul de tip dropdown permite specificarea ușoară a procentului în care se dorește vizualizarea suprafeței de design.

HTML5 Report Viewer

Este un compozit format din widget-uri Telerik Kendo UI, al cărui șablon este format din tre fișiere : HTML (User Interface), CSS (stiluri), JS (funcționalitate). Scopul Html5 Report Viewer este să afișeze rapoare Telerik și să permită utilizatorului să interacționeze cu ele. Rapoartele sunt procesate și randate pe server unde motorul Telerik Reporting și serviciile Reporting REST rulează. Rapoartele și serviciile lor sunt livrate către viewer cu ajutorul serviciul de REST Reporting. Conținutul viewer-ului este randat în elemente div.

Zona de previzualizare oferă spațiu pentru vizualizarea raportului randat. Toate comenzile oferite de toolbar operează cu raportul afișat la momentul curent. Toobar-ul oferă diverse funcționalități, cum ar fi : navigarea înainte și înapoi, refresh, direcționarea către prima pagină, următoarea pagină , ultima pagină, exportarea raportului în diferite formate, printarea acestora.

3.5 ASP.NET MVC și ASP.NET Web API

Active Server Pages (ASP)

Primul răspuns al celor de la Microsoft relativ la programarea web a fost Active Server Pages (ASP), un limbaj de script în care codul și markup-ul sunt autorizate împreună în aceeași pagină, cu fiecare pagină fizică corespunzând unei pagini web. Abordarea ASP a server side scripting-ului devine populară și multe website-uri s-au fondat pe baza ei. Unele dintre aceste site-uri mai servesc vizitatorii chiar și în ziua de azi. După un timp, programatorii au început să ceară din ce în ce mai mult, cererile constând în îmbunătățirea refolosirii codului, o separare a conceptelor mai bună, o aplicabilitate mai ușoară a principiilor de programare orientată pe obiect. În 2002, Microsoft oferă ASP.NET ca soluție la aceste probleme.

ASP.NET MVC

Prima versiune a apărut în 2008 și reprezenta o separare totală de abordarea ASP.NET Web Forms, astfel că ASP.NET MVC abandonează total arhitectura bazată pe pagini, reprofilându-se pe arhitectura Model-View-Controller. În concluzie, ASP.NET MVC și Web Forms sunt modalități diferite de a construi un website ASP.NET.

Arhitectura Model-View-Controller

Această arhitectură încurajează stricta izolare între părțile individuale ale unei aplicații. Tiparul MVC separă aplicația în 3 nivele: modelul, view-ul și controller-ul. Fiecare dintre acestea are câte o sarcină specifică iar cel mai important lucru este că nu depinde de sarcina celuilalt.

Figura . Arhitectura MVC

Modelul

Acesta reprezintă nucleul logicii de afaceri și datele. El încapsulează proprietățile și comportamentul unei entități și expune proprietățile descrise de aceasta. De exemplu, dacă luăm o clasă denumită Licitație pentru ea vom avea proprietăți precum Titlu și OfertaCurentă, dar și expunere de comportament sub forma unor metode ca Oferta( ).

View-ul

Este responsabil pentru transformarea modelului într-o reprezentare vizuală. În aplicațiile web acest lucru înseamnă de obicei generarea HTML-ului pentru a fi randat în browser-ul user-ului, deși View-urile se pot manifesta în mai multe forme. De exemplu, același model poate fi vizualizat în HTML, PDF, XML sau într-o foaie de calcul. View-urile se concentrază numai pe afișarea și nu trebuia să conțină logică – aceasta rămâne în model.

Controller-ul

După cum sugerează și numele, acesta controlează logica aplicației și se comportă ca un coordonator între Model si View. Controllerele primesc date de la utilizatori prin intermediul view-ului, apoi lucrează cu modelul pentru a realiza acțiuni specifice, transmițând rezultatele înapoi la View.

Figura . Ciclul de viață al unui request ASP.NET MVC

ASP.NET WEB API

Este o platformă ce permite crearea de servicii HTTP care ajung la o gamă largă de clienți, cum ar fi browsere sau dispozitive mobile. Web API permite returnarea de date conform cu cerințele clienților. Implicit, WebAPI oferă răspunsuri în format JSON și XML.

Figura . Arhitectura WEB API

REST este acronimul pentru Representational State Transfer, acesta este un protocol pentru schimbul de date în cadrul unui mediu distribuit. Ideea principală din spatele acestui protocol este că trebuie să tratăm serviciile distribuite ca pe o resursă și că putem folosi protocoale HTTP simple pentru a întreprinde diferite operații asupra acelei resurse.

Când ne referim la o bază de date ca la o resursă trebuie să aducem în discuție automat și operațiile CRUD, ce reprezintă: Create, Retrieve, Update și Delete. REST ne ajută să implementăm aceste operații pe o resursă oarecare. Operațiile CRUD de bază sunt mapate la protocoalele HTTP în următoarea manieră :

GET : acesta mapează operația Retrieve. Va fi folosit pentru a returna datele cerute de client de la o anumită resursă;

PUT : acesta mapează operația Update. Protocolul va actualiza datele curente de pe resursă;

POST : acesta mapează operația Create. Se va crea o nouă înregistrare pentru datele curente care au fost trimise de pe server;

DELETE : acesta mapează operația Delete. Se vor șterge datele specificate de pe server.

Rutarea

În ASP.NET WEB API requesturile HTTP sunt manipulate de către un controller. Metodele publice ale acestuia sunt denumite metode acțiune sau, mai simplu, acțiuni. Când Web API primește un request, el îl transmite unei acțiuni. Pentru a determina ce acțiune să invoce, platforma utilizează un tabel de routing.

Template-ul utilizat de către Visual Sudio pentru Web API creează o rută implicită:

routes.MapHttpRoute(

name: "API Default",

routeTemplate: "api/{controller}/{id}",

defaults: new { id = RouteParameter.Optional }

);

Această rută este definită în fișierul WebApiConfig.cs, care este localizat în directorul App_Start.

Fiecare înregistrare din tabela de routing conține o rută șablon. Ruta implicită pentru Web API este "api/{controller}/{id}". “api” este calea, iar {controller} și {id} sunt variabile înlocuitoare.

Când Web API primește un request, el încearcă să potrivească URI-ul cu una dintre rutele definite în tabela de rutare. Dacă nu se potrivește cu niciuna, clientul va primi o eroare 404. De exemplu, următorii URI se potrivesc cu ruta implicită :

/api/contacts

/api/contacts/1

/api/products/gizmo1

Următorul URI nu se potrivește deoarece îi lipsește segmentul “api” : /contacts/1

Segmentul "api" se folosește în rută pentru a evita coloziunile cu rutarea ASP.NET MVC. Așadar, pentru un controller MVC avem  "/contacts", iar pentru un controller Web API folosim "/api/contacts".

Să presupunem că avem următorul controller:

public class ProductsController : ApiController

{

public void GetAllProducts() { }

public IEnumerable<Product> GetProductById(int id) { }

public HttpResponseMessage DeleteProduct(int id){ }

}

În tabelul de mai jos sunt prezentate posibile request-uri împreună cu acțiunile care sunt invocate pentru fiecare:

Request-ul de tip POST nu va reuși deoarece în controller nu avem nicio metodă POST.

Bibliografie

Cătălin Maican, Radu Lixăndroiu, Sisteme informatice pentru managementul conținutului, Editura , Brașov, anul.

WTC Functional Specification – DCI Confidential

Ian Griffiths, Programming C# 5.0, O’Reilly Media, 2012

Julia Lerman, Rowan Miller, Programming Entity Framework : Code First, O’Reilly Media, 2011

Jess Chadwick, Todd Snyder, Hrusikesh Panda, Programming ASP.NET MVC 4, O’Reilly Media, 2012

***http://www.dwk.ro/?page=Mitglieder&subpage=Unsere_Mitglieder&unternehmen=DCI%20Database%20for%20Commerce%20and%20Industry%20Romania%20SRL

*** http://www.tutorialesql.com/despre-sql/

*** https://msdn.microsoft.com/en-us/ms174173.aspx

***http://www.entityframeworktutorial.net/EntityFramework5/entity-framework5-introduction.aspx

***http://www.entityframeworktutorial.net/code-first/entity-framework-code-first.aspx

*** http://www.telerik.com/help/reporting/overview.html

*** http://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-in-aspnet-web-api

Bibliografie

Cătălin Maican, Radu Lixăndroiu, Sisteme informatice pentru managementul conținutului, Editura , Brașov, anul.

WTC Functional Specification – DCI Confidential

Ian Griffiths, Programming C# 5.0, O’Reilly Media, 2012

Julia Lerman, Rowan Miller, Programming Entity Framework : Code First, O’Reilly Media, 2011

Jess Chadwick, Todd Snyder, Hrusikesh Panda, Programming ASP.NET MVC 4, O’Reilly Media, 2012

***http://www.dwk.ro/?page=Mitglieder&subpage=Unsere_Mitglieder&unternehmen=DCI%20Database%20for%20Commerce%20and%20Industry%20Romania%20SRL

*** http://www.tutorialesql.com/despre-sql/

*** https://msdn.microsoft.com/en-us/ms174173.aspx

***http://www.entityframeworktutorial.net/EntityFramework5/entity-framework5-introduction.aspx

***http://www.entityframeworktutorial.net/code-first/entity-framework-code-first.aspx

*** http://www.telerik.com/help/reporting/overview.html

*** http://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-in-aspnet-web-api