Cei care sunt obișnuiți să se gândească la CRM numai ca un mijloc de marketing și management de marketing, merită să ne gândim din nou. Gestionarea relațiilor cu clienții (CRM) este o platformă pentru dezvoltarea de aplicații care gestionează și urmăresc informațiile și procesele legate de obiectele fizice. Aceste obiecte pot fi clienți, dar pot fi, de asemenea, aproape orice entitate (și acțiuni conexe) pe care trebuie să o gestionați.
Ca și în cazul oricăror soluții la scară largă, individualizate, este necesar să se înțeleagă anumite baze legate de implementare. În acest articol am de gând să acopere unele concepte fundamentale legate de implementarea Microsoft Dynamics CRM, inclusiv modul în care aceste concepte pot fi folosite pentru a sprijini desfășurarea ciclului de viață al produsului complet. De asemenea, voi vorbi despre gestionarea mai multor implementările ca parte a problemei cu o singură soluție și că, atunci când serviciul este una din mai multe exemplu de implementare a aplicației ar trebui să fie utilizate ca parte a întregului ciclu de viață soluție, și când nu.
De la începutul acestui articol, aș dori să clarific faptul că atunci când vorbim de soluția Microsoft Dynamics CRM, mă refer la cantitatea totală de modificări, extensii, cod de utilizator, modificări ale schemelor și așa mai departe. Soluția nu este un singur lucru, ci toate schimbările luate împreună.
În esență, Microsoft Dynamics CRM este o aplicație standard, bazată pe date, ASP.NET 2.0 și Microsoft .NET Framework 3.5. Sistemul cu trei niveluri include următoarele componente mari.
Soluția de dezvoltare a ciclului de viață
Soluția Microsoft Dynamics CRM rulează în același ciclu ca orice proiect de dezvoltare pentru o aplicație particularizată, care poate fi similară cu procesul prezentat în Fig. 1.
Fig. 1. Ciclul de dezvoltare a aplicațiilor
Întregul proces va fi susținut de mai multe medii, care împreună alcătuiesc sistemele de dezvoltare, testare și producție. În lumea oricărei aplicații multiple a întreprinderii, acest lucru, desigur, poate fi surprinzător de complex. Dacă, de exemplu, doriți să creați o imagine oglindă a suportului media, rezultatul poate fi similar cu cel prezentat în Fig. 2.
Fig. 2. Oglindirea mijloacelor de dezvoltare, testare și medii de producție
Acestea sunt trei domenii, trei controlere de domeniu, trei servere de e-mail, trei servere web și trei servere de baze de date - și acest model presupune că SRS și CRM se află pe același bloc fără să țină cont de sarcini precum echilibrarea încărcării. Acum, să ne imaginăm adăugarea redundanței și a mai multor servicii externe, cum ar fi Microsoft Office SharePoint Services (MOSS), și o schemă similară cu cea prezentată în Fig. 3.
Fig. 3 Creșterea complexității
În ceea ce privește costurile și complexitatea, se poate gândi la compromisuri între nevoia de izolare a mediului și necesitatea de a reduce costurile și de a îmbunătăți gestionabilitatea. Prin urmare, organizațiile s-au transformat într-o varietate de tehnici, cum ar fi virtualizarea și funcțiile integrate de a servi o singură instanță de aplicație a multiplelor implementări ale Microsoft Dynamics CRM pentru a rezolva aceste sarcini.
În schimb, alții cred că o astfel de izolare nu contează deloc. Dacă ar putea, ar fi implicați în dezvoltarea și testarea directă în mediul de producție. Ei tind să vadă redundanța ca pierdere de timp și bani și sunt convinși că dăruirea rezultatelor ar fi mai ușoară dacă ați putea urca pur și simplu în sistem și să facem totul să funcționeze.
Se speră că cititorii vor cădea undeva între aceste două cazuri extreme, și va deschide ideea că, atunci când este vorba de decizia pe baza Microsoft Dynamics CRM, este posibil să se creeze un hibrid, în cazul în care echilibrată complexitate, costuri, izolarea și manipulare.
Elemente ale soluției CRM
Componentele soluției Microsoft Dynamics CRM pot fi împărțite în patru pachete mari și soluția poate include una dintre ele, două, trei sau toate cele patru.
Modificări Acestea includ modificări ale formelor, tabelelor, schemelor și metadatelor; rolul securității; procese de lucru; setările de sistem și șabloanele. Modificările la Microsoft Dynamics CRM sunt furnizate ca unul sau mai multe (de obicei unul sau două) fișiere zip din XML. Acestea sunt importate în implementarea CRM prin Outlook sau în zona "Special settings" a clientului web și apoi "publicate" pentru a le face active. Toate acestea pot fi automatizate utilizând codul scris pentru SDK-ul Microsoft Dynamics CRM.
Cod personalizat Tot ceea ce este conceput ca parte a unei soluții - poate fi alcătuit din servicii web externe, componente de aplicații web personalizate și așa mai departe. Regulile și practicile pentru implementarea codului personalizat nu trebuie să fie diferite de cele pentru orice altă aplicație web particularizată.
Date Toate informațiile de care aveți nevoie pentru a importa în mediul înconjurător pentru funcționarea acestui mediu. Aceasta poate include date de domeniu (cum ar fi o listă de coduri de produse) sau utilizatori. Datele soluție necesare, pot fi implementate în Microsoft Dynamics CRM exemplu utilizând un script sau CRM cod funcție lot de import, sau prin utilizarea oricărei forme de proces extern folosind BizTalk sau alte mijloace ETL (Extract, transformare, încărcare - extract, transforma și descărcări). Unele date, cum ar fi datele de utilizator, trebuie să creați manual sau prin intermediul SDK-ul Microsoft Dynamics CRM apeluri.
Prefer sa ma gandesc la implementarea solutiilor CRM ca si cum ar fi implementarea dezvoltarii propriilor aplicatii. Acest lucru înseamnă că în timpul desfășurării și testării, fiecare nou ansamblu de soluții este instalat dintr-un sistem de bază curat, procesul fiind astfel repetabil și funcționează în funcție de scenariu.
Cât despre deservirea mai multor instanțe ale aplicației cu o singură instanță de aplicație?
La prima vedere, acest lucru poate părea un panaceu, oferind un răspuns la toate ghicitorile de controlabilitate, izolare și costuri. O astfel de soluție poate fi vizualizată, așa cum se arată în Fig. 4.
Fig. 4. O soluție integrată pe întreținerea mai multor implementări de către o instanță de aplicație
Acest lucru pare logic, deoarece fiecare organizație are o bază de date fizică proprie pe un SQL Server sau o instanță comună (care include utilizatori, modificări, fluxuri de lucru, roluri și setări) și propriul dosar SQL Reporting Services.
Luați, de exemplu, aceste adrese URL: crmserver / ContosoDevOrg / loader.aspx și crmserver / ContosoTestOrg / loader.aspx. Serverul CRM caută în directorul rădăcină pentru a determina numele organizației care ar trebui să fie deservită. Dacă numele organizației rădăcină nu este găsit, ca în cazul crmserver / loader.aspx, serverul utilizează prima organizație implicită creată în implementare în mod prestabilit sau cea la care apelantul are acces.
Deoarece ambele organizații au folosit același site, în cazul în care în decizia au cod personalizat, acesta va fi, de asemenea, în comun de cele două organizații, de exemplu crmserver / ContosoDevOrg / ISV / mycustomdialog.aspx și crmserver / ContosoTestOrg / ISV / mycustomdialog.aspx.
Ambele indică același fișier fizic de pe disc, cum ar fi C: # 92; inetpub # 92; wwwroot # 92; isv # 92; mycustomdialog.aspx. Deoarece este probabil ca versiunea extensiei personalizate în mediile de producție, testare și dezvoltare să varieze, aceasta poate reprezenta o problemă serioasă. Să presupunem, de exemplu, că un ansamblu al celor 11 aplicații este în prezent în curs de dezvoltare, în timp ce ansamblul 9 se află la etapa de testare produsă de utilizatori. Dacă încercați să utilizați o instanță a mai multor aplicații pentru a rezolva problemele cu mediul, izolarea celor două ansambluri va fi dificilă. În astfel de situații, soluția prezentată în Fig. 5.
Fig. 5. Încercați să utilizați diferite servere IIS pentru a separa codul pentru soluții personalizate
Mediul de lucru 192.168.1.110/Contoso/loader.aspx
Acest model vă permite să aveți trei servere separate de Access Client care găzduiesc trei organizații diferite, cu trei baze de cod diferite pe disc. Până când utilizatorul nu apasă din greșeală o organizație incorectă pe un server greșit, totul ar trebui să funcționeze perfect.
Din păcate, din moment ce toate serverele Client Access sunt considerate a fi parte din aceeași desfășurare, dificultăți de a începe să apară un pic mai departe în proces decât ar putea părea la prima vedere. Aceasta devine o problemă reală în cazul în care soluția utilizează asincrone add-in-uri sau fluxuri de lucru, deoarece, în ciuda faptului că este posibil să se controleze serverele care un utilizator se conectează off, controlul pe care serviciul asincron va procesa evenimente și cereri, pentru care organizația este imposibilă.
Acest lucru se datorează faptului că toate serviciile asincrone într-o lucrare de implementare într-un mod ciclic, și din cauza acestui server asincron de implementare serviciu poate ocupa de sarcina de răspuns al sistemului de flux de lucru sau asincron add-on cererea de server de test, încălcând astfel cerința de excludere imediată. În plus, în cazul în care codul personalizat care ruleaza acest proces asincron se bazează pe fișiere care trebuie să fie implementate pe un server conectat la disc (cum ar fi un fișier de configurare sau în cache-ul de asamblare la nivel mondial - Global Assembly Cache / CAG), atunci orice conflicte de versiune.
Este important de observat că, în cea mai mare parte, aceste probleme apar doar atunci când se scrie cod personalizat care trebuie să fie implementat pe disc sau dacă acest cod se bazează pe resurse care vor fi disponibile numai pe un anumit server sau din acesta. Dacă aplicația este simplă și utilizează numai fluxuri de lucru și rapoarte de modificări (scheme, formulare, vederi și așa mai departe), atunci problemele cu abordarea din Fig. 4 nu ar trebui să apară.
Deci, care este scopul servirii multiplelor implementări pentru o singură instanță de aplicație și când este o soluție bună pentru mediile ciclului de viață al produsului? Servirea instanțelor multiple ale unei aplicații cu o singură instanță a aplicației a fost inițial concepută pentru a rezolva problemele hardware asociate cu implementarea mai multor implementări diferite într-un mediu de producție și le rezolvă foarte bine. Anterior, în Microsoft Dynamics CRM 3.0, fiecare implementare a trebuit să aloce propria instanță a SQL Server sau SQL Server, precum și serverul Client Access.
Copilul a fost din mai multe motive, inclusiv faptul că parametrii relevanți pentru implementare au fost apoi stocați în registru și pe disc. Toate aceste configurații s-au mutat în baza de date, astfel încât un singur server de aplicații poate servi mai multe organizații. Servirea instanțelor multiple ale unei aplicații cu o singură instanță a aplicației este utilă pentru versiunile găzduite de CRM, inclusiv pentru Microsoft Dynamics CRM Online.
Considerații privind dezvoltarea
Acum, că cititorii știu despre unele probleme potențiale, să ne gândim la unele puncte care ar trebui luate în considerare atunci când se dezvoltă o implementare. Răspunsul, desigur, este că totul depinde de situație. Categoric este posibil pentru a rula un mediu CRM complet (inclusiv controler de domeniu, SQL server și server web) pe același computer, așa cum se poate vedea în demonstrarea Microsoft Dynamics CRM 4.0 Virtual Machine (a se vedea. Sidebar „pe Materiale CRM“ pentru URL-ul). Imaginea virtuală a unui singur computer este foarte des folosită pentru mediul de dezvoltare. Dar pentru testare, este important să verificați sarcinile esențiale ale mediului de producție și, din acest motiv, recomandăm ca mediul de testare să reflecte mediul de producție în ceea ce privește structura, dar nu și capacitatea. Mediul poate arăta similar cu cel prezentat în Fig. 6.
Fig. Structura mediului de testare ar trebui să reflecte structura producției
Această abordare încearcă să reducă la minimum numărul de dispozitive de infrastructură fizică prin utilizarea de virtualizare și încercări suplimentare pentru a minimiza resursele de virtualizare prin virtualizarea doar scenarii cheie care trebuie să fie testate. Acest lucru va oferi dezvoltatorilor posibilitatea de a efectua procesare pe o singură imagine de server (sau, în cazul în care au propriul lor calculator virtual sau desktop-uri personale) în cazul în care vă asigura că acestea vor acorda o atenție la mediul în care acestea vor fi implementate soluții. Întrebările pe care dezvoltatorii ar trebui să le acorde atenție sunt aceleași întrebări pe care ar trebui să le creați propriul mediu pentru verificare, inclusiv următoarele.
Asigurarea personalizabilității Nu presupuneți, de exemplu, că serverul va răspunde la un nod local sau la un anumit port.
Contabilizarea mai multor servere Nu presupuneți că totul va funcționa fără instalarea de utilizatori proxy sau de încredere pentru delegație.
Contabilitatea pentru echilibrarea încărcării Trebuie să fii foarte atent la starea sesiunii și la cache. Rețineți că Microsoft Dynamics CRM este proiectat să nu salveze deloc starea și funcționează bine cu un balancer de încărcare ciclic.
Contabilitate pentru întreținerea implementărilor multiple de către o instanță a unei aplicații Atunci când mai multe implementări sunt găzduite pe același computer, aceștia au același spațiu de procesare. Acest lucru înseamnă că elemente similare cu cache-urile trebuie să fie atașate la numele organizației pentru a împiedica utilizatorii să utilizeze neintenționat date dintr-o organizație de la alta. În plus, dacă aveți cod de client care are legături sau apeluri înapoi la server, trebuie să vă asigurați că apelurile stochează numele organizației în URL; altfel puteți ajunge la organizația implicită sau nu la cea așteptată.
Materiale pe CRM
Gânduri cheie
Izolarea este importantă Atunci când dezvoltați o soluție, amintiți-vă ce abordare (așa cum este ilustrat în Figurile 4, 5 și 6) este cea mai potrivită pentru situație și luați în considerare locul în care codul generat poate funcționa. De remarcat, de asemenea, când nu trebuie să vă faceți griji în privința unor astfel de probleme, în virtutea tipului de extensii utilizate de soluție.
Virtualizarea virtualizare ajută la reducerea complexității creării unui mediu care să reflecte scenariile-cheie pentru testarea mediului de producție. Voi da un mic sfat despre pregatire. Plasați CRM și SQL Server pe diferite servere. Acest lucru ajută la verificarea relației de încredere în ceea ce privește delegarea și problemele conexe. Încărcarea pe serverele CRM trebuie să fie echilibrată, ceea ce ajută la determinarea problemelor legate de cache, sesiuni și de la server la server. În cele din urmă, puneți controlerul de domeniu și e-mailul pe servere separate; acest lucru ajută la identificarea problemelor de conectare.
Actualizarea mediului pentru fiecare ansamblu, ca regulă generală, o idee bună este de a crea o copie de rezervă sau medii virtuale, baze de date sau doar Microsoft Dynamics CRM (date și configurare), care poate fi apoi restaurat pentru a readuce serverul la starea sa normală. După aceasta, de fiecare dată când se efectuează o desfășurare curată completă într-un mediu proaspăt; inclusiv codul de utilizator, modificări, adiționali și date de domeniu.
Testarea performanței / redundanței poate fi efectuată separat. Cu excepția organizațiilor foarte mari, toleranța la erori și testarea performanțelor pot fi realizate de obicei prin simulări izolate, nu prin extensii la sistemul real. Aceasta înseamnă că nu este nevoie să creați un mediu de testare care să permită testarea unor astfel de scenarii. Alternativ, puteți să vă bazați pe testarea lor, fie în producție, fie în medii separate de unică folosință.
În concluzie, putem spune că Microsoft Dynamics CRM este un sistem scalabil la nivel de corporație care, atunci când este configurat și implementat corespunzător, poate servi grupuri mici, soluții pentru întreaga întreprindere și toate opțiunile dintre ele. Determinarea mediului de ciclu de viață al produsului care este adecvată într-un anumit caz va depinde de o serie de factori.
În general vorbind, de serviciu o instanță a aplicării mai multor implementările nu este modul ideal de a rezolva problemele ciclului de viață de dezvoltare a produsului în soluții complexe, și este de dorit să se folosească numai în caz de înțelegere completă. Soluțiile simple care necesită numai setări de bază sau utilizează soluții de utilizator scrise și izolate adecvat, care nu se bazează pe resursele de disc sau accesul la un anumit server, ar trebui să funcționeze bine, urmând modelul descris în Fig. 4.
Dacă soluția necesită izolare suplimentară, resurse specifice serverului sau acces (poate că un serviciu extern este permis numai prin VLAN de la un anumit server la altul), vă recomandăm să urmați modelul prezentat în Fig. 6. De asemenea, recomand să evitați abordarea ilustrată în Fig. 5. Pentru că este, în cel mai bun caz, un hibrid construit în grabă.
În cele din urmă, Microsoft Dynamics CRM poate fi implementat în mii de configurații și care dintre acestea abordează situația depinde de nevoile soluției. Cu o mai bună înțelegere a unui serviciu de aplicare mai multe implementări exemplu, medii de implementare cu un singur server de, mediile virtuale de testare, și ce scenarii testabile sunt relevante, dezvoltatorul ar trebui să fie în măsură să dezvolte o implementare a ciclului de viata, care este atât funcțional și economic.
Articole similare
Trimiteți-le prietenilor: