SharePoint un Dynamics 365: integrācija bez dublētiem datiem

Ievads

Daudzās organizācijās problēma nav dokumentu trūkums, bet gan tas, ka tie dzīvo atsevišķi no klientu, darījumu un lietas procesa datiem. Tad komanda meklē līgumu vienā vietā, komentē to citā, bet gala statusu redz vēl citā sistēmā. Tieši šeit SharePoint un Dynamics 365 savienojums kļūst praktisks: SharePoint glabā dokumentus un versijas, bet Dynamics 365 tur procesu, ierakstu saistību un lietotāju darbu pie konkrēta klienta vai pieteikuma. Šī kombinācija strādā labi, ja dokumentu vadība ir piesaistīta konkrētam biznesa objektam, nevis izmantota kā vispārīga failu noliktava. Konsultanta ikdienā robeža parasti parādās tur, kur organizācija mēģina ielikt SharePoint visu: arī strukturētu darījumu loģiku, apstiprināšanas ķēdes un integrācijas ar citiem datu avotiem. Tad jānosaka, kurš ir sistēmas “avots patiesībai”, kāds ir dokumentu dzīves cikls un kurā brīdī lietotājs paliek Dynamics 365, nevis pārlec uz SharePoint. Praktiskā pieeja nozīmē arī drošības un uzturēšanas robežas: SharePoint tiek konfigurēts dokumentiem un sadarbībai, bet Dynamics 365 paliek procesa vadībai un auditējamam klienta ierakstam. Tāpēc integrāciju nav jēga sākt ar tehnisko savienojumu vien; sākums ir ar scenāriju, kuram piešķir vienu skaidru atbildīgo sistēmu, vienu dokumentu atrašanas principu un vienu noteiktu lietotāja ceļu no ieraksta līdz failam.

Kad SharePoint ir dokumentu slānis, nevis procesa dzinējs

Ja SharePoint mēģina aizstāt procesu, sākas fragmentācija: viens dokuments dzīvo bibliotēkā, statuss – citā sarakstā, bet darījuma konteksts – Dynamics 365 ierakstā. Konsultanta praksē problēma parādās brīdī, kad cilvēki dokumentu atrod, bet nezina, pie kura klienta vai lietas tas pieder, jo platforma ir kļuvusi par failu noliktavu, nevis procesa vadības vietu. SharePoint šeit strādā kā dokumentu slānis: glabā failu, versijas, metadatus un piekļuvi, kamēr procesu tur Dynamics 365. Tas saskan ar pieeju, kur datu izgūšanā no servera iegūst tikai minimālo nepieciešamo datu apjomu, nevis visu, kas pieejams [1].

Cēlonis parasti ir mēģinājums ielikt visus biznesa noteikumus dokumentu bibliotēkas kolonnās vai padarīt SharePoint par vienīgo lietas avotu. Pareizā robeža ir skaidra: Dynamics 365 uztur klienta, darījuma vai lietas dzīves ciklu, bet SharePoint tur dokumentu komplektu, kas piesaistīts šim ierakstam. Praktiskais ieviešanas modelis sākas ar struktūru:

• izveido SharePoint dokumentu bibliotēku vienam scenārijam, nevis visiem procesiem kopā;
• definē minimālu metadatu kopu, kas tieši atbilst Dynamics 365 ierakstam;
• iestata piekļuvi bibliotēkai pēc lomām, nevis pēc individuāla faila;
• panāk, ka ieraksta identitāte dzīvo Dynamics 365, bet dokuments tiek sasaistīts ar to caur bibliotēku vai kartīti.

Kā pārbaudīt, ka tas strādā: lietotājs atver klienta kartīti Dynamics 365, redz dokumentu sarakstu, atver failu SharePoint vidē un atgriežas tajā pašā kontekstā bez manuālas meklēšanas. Ja dokumentu meklēšana notiek pēc lietas vai klienta metadatiem, nevis tikai pēc faila nosaukuma, dokumentu slānis ir pareizi nodalīts no procesa dzinēja. Tieši šeit sākas robeža, aiz kuras integrācija kļūst vērtīga arī līgumu un klientu lietu vadībā.

SharePoint un Dynamics 365 integrācija klientu lietu un līgumu vadībai

Tipiska kļūda praksē ir mēģinājums sinhronizēt visu dokumentu dzīvi abos virzienos: līgums tiek pārdēvēts SharePoint pusē, statuss tiek pārrakstīts Dynamics 365 pusē, un komanda pēc tam vairs nezina, kurš ir sistēmas avots. Šāda pieeja rada dublikātus, konflikta situācijas un atbalsta pieprasījumus par to, kurš fails ir “īstais”. Šī kļūda rodas tāpēc, ka integrācijā netiek noteikts īpašnieks: vai procesam uzticēts Dynamics 365 ieraksts, vai dokumentu pārvaldībai uzticēts SharePoint.

Praktiski pareizā konfigurācija sākas ar vienu galveno saiti starp objektiem. Dynamics 365 ir jāuztur klients, lieta vai līgums, bet SharePoint jāuztur ar šo ierakstu saistītie dokumenti. Ja integrācija tiek būvēta on-premises vidē, tehniskajā pusē jāņem vērā servera drošības prakse: Dynamics 365 Server Setup izveido CRMAppPool un CRMDeploymentServiceAppPool, un ieteikts tiem norādīt atsevišķus domēna lietotāju kontus, nevis Network Service kontu [2]. Tas ir svarīgi arī dokumentu scenārijos, jo integrācija balstās uz identitāti, autentifikāciju un datubāzes piekļuvi.

Praktiskais ieviešanas ceļš:

1. Dynamics 365 pusē definē, kurš objekts ir primārais: Account, Case, Contract vai cits biznesa ieraksts.
2. SharePoint pusē izveido dokumentu bibliotēku ar skaidru nosaukumu un vienu atbildīgo lietojuma modeli.
3. Piesaisti dokumentu bibliotēku pie Dynamics 365 ieraksta, lai lietotājs dokumentu atver no konteksta, nevis meklē mapju hierarhijā.
4. Ieplāno, ka metadati tiek pārmantoti no ieraksta, nevis ievadīti katram failam no jauna.
5. Pārbaudi, ka lietotājam ir piekļuve gan ierakstam, gan bibliotēkai, citādi integrācija izskatās kā “salūzis links”.

Ja šo neizlabo, sekas parādās ļoti ātri: lietotāji sāk turēt līguma versijas e-pastā, SharePoint dokumentu bibliotēka kļūst par paralēlu arhīvu, bet Dynamics 365 zaudē savu nozīmi kā procesa vadības vide. Tieši tāpēc integrācija nav tikai savienojums starp sistēmām, bet arī disciplīna, kur skaidri nosaka, kas kurai platformai pieder. Tālāk loģiski jāskatās, kā versijas, metadata un piekļuve strādā vienā lietotāja plūsmā.

Dokumentu versijas, metadata un piekļuve vienā lietotāja plūsmā

Dokumentu pārvaldībā praktiski vienmēr ir divas pieejas. Pirmā pieeja koncentrējas uz failu versijām un piekļuvi: lietotājs redz dokumentu, rediģē to, un SharePoint uztur izmaiņu vēsturi. Otrā pieeja koncentrējas uz metadata un procesa kontekstu: dokumentam ir klients, līguma tips, termiņš, atbildīgais un statuss, lai to varētu atrast un filtrēt darba gaitā. Pirmais variants der tad, ja komanda strādā ar nelielu dokumentu apjomu un galvenais ir redzēt, kas mainījies. Otrs variants der, ja dokumentu plūsma ir saistīta ar procesu, piemēram, līgumu saskaņošanu vai klientu lietu uzturēšanu.

Praksē labākais risinājums ir šo pieeju nevis pretnostatīt, bet sakārtot slāņos. SharePoint nodrošina versiju kontroli un dokumentu piekļuvi, savukārt Dynamics 365 uztur biznesa kontekstu. Ja dokumenta izmaiņas ir kritiskas, jāliek uzsvars uz SharePoint versijām; ja dokumenta meklēšana un filtrēšana ir svarīgāka, jādod priekšroka metadata disciplīnai. Drošības pusē Microsoft uzsver, ka produktīvās vidēs debugging ir jāatspējo un klientam problēmas gadījumā jāsniedz vispārīgs kļūdas ziņojums [2]. Tas pats princips attiecas uz dokumentu plūsmu: lietotājam rāda vienkāršu rezultātu, bet sistēmā saglabā precīzu tehnisko informāciju.

Ja jāizvēlas, kā organizēt lietotāja plūsmu, ieteikums ir šāds:

• ja process balstās uz dokumenta rediģēšanu, vispirms sakārto versiju kontroli un tikai tad paplašini metadata;
• ja process balstās uz dokumentu atrašanu pēc lietas vai klienta, vispirms definē obligātos laukus un meklēšanas principu;
• ja piekļuve ir sensitīva, nodali bibliotēkas vai mapes pēc biznesa lomas, nevis pēc nejaušas failu loģikas;
• ja dokumentu lieto vairākas komandas, saglabā vienu kopīgu avotu, nevis lokālas kopijas.

Rezultātā lietotājs strādā vienā plūsmā: atver ierakstu, redz dokumenta versiju, pārbauda metadatus un turpina darbu bez pārlēkšanas starp vairākām vietām. Tas samazina situācijas, kur “pareizais dokuments” eksistē, bet nav atrodams kontekstā. Nākamais jautājums ir, kad šo plūsmu labāk nepadarīt automātisku, jo tieši tur rodas nevajadzīgas sinhronizācijas problēmas.

Kad dokumentu sinhronizāciju labāk netaisīt automātisku

Automātiska dokumentu sinhronizācija izskatās ērta līdz brīdim, kad biznesa noteikumi sāk konfliktēt ar failu kustību. Ja dokumenti tiek masveidā kopēti starp Dynamics 365 un SharePoint bez skaidras kontroles, rodas dublikāti, lieka tīkla slodze un neskaidrība par to, kura versija ir jālieto. Tāpēc sinhronizāciju ieslēdz tikai tad, kad ir skaidrs, kurš avots ir primārais un kā lietotājs strādā ar dokumentu ikdienā. Dynamics 365 dokumentācijas labāko prakšu sadaļa norāda, ka veiktspējas dēļ ieteicams atvērt vairākus pavedienus, automātiski ģenerēt GUID un servera pusē iegūt tikai minimālo nepieciešamo datu apjomu [1]. Tas pats domāšanas modelis dokumentu integrācijā nozīmē: nepārsūtīt vairāk, nekā lietotājam vajag konkrētajā brīdī.

Praktiska instrukcija, kad automātiku neuzlikt bez pārbaudes:

1. Atver Dynamics 365 ieraksta dokumentu karti un pārbaudi, vai dokumentu bibliotēka tiešām ir nepieciešama katram lietotājam.
2. SharePoint pusē Document Library iestatījumos noskaidro, vai bibliotēkai ir skaidra versiju un piekļuves loģika.
3. Ja integrācijā iesaistīti on-premises serveri, pārbaudi autentifikāciju un SPN iestatījumus, jo SPN tiek izmantots savstarpējai autentifikācijai starp klientu un serveri, kas izvieto pakalpojumu [2].
4. Testē, vai lietotājs dokumentu atver no ieraksta, nevis meklē to atsevišķi SharePoint vidē.
5. Ja sinhronizācija rada dublikātus vai aizkavēšanos, atstāj dokumentu sasaisti pēc pieprasījuma, nevis pilnīgi automātisku izplatīšanu.

Biežākā kļūme šajā solī ir pārlieku plašs “auto-sync” iestatījums, kas pārnes arī dokumentus, kuri nav vajadzīgi katrai lomai vai katram procesam. Otra kļūme ir piekļuve: ja lietotājs redz ierakstu Dynamics 365 pusē, bet nevar atvērt saistīto bibliotēku SharePoint pusē, integrācija izskatās kā bojāta, lai gan problēma ir tiesībās. Trešā kļūme ir uzturēšana: ja automātiku uzbūvē bez skaidras robežas, vēlāk ir grūti noteikt, kur tiek ģenerēti faili un kur tie tiek glabāti. Tāpēc šis ir brīdis, kad konsultants izvēlas kontroli, nevis ērtības soli bez robežām. Kad šī robeža ir saprasta, integrāciju var būvēt droši un saprotami arī līgumu un klientu lietu scenārijos.

Drošības robežas: kas paliek Dynamics 365 un kas nonāk SharePoint

Drošības robeža starp SharePoint un Dynamics 365 sākas nevis pie dokumenta, bet pie datu īpašumtiesībām. Dynamics 365 tur lietas procesu, ieraksta statusu, saistību ar klientu un piekļuves loģiku, savukārt SharePoint glabā dokumenta saturu, versijas un sadarbības darbu. Praksē tas nozīmē vienkāršu principu: ja lauks nosaka biznesa procesu, tas paliek Dynamics 365; ja objekts ir fails, kas dzīvo rediģēšanas un versiju ciklā, tas nonāk SharePoint. Šāds dalījums samazina situācijas, kur viens un tas pats dokuments tiek pārrakstīts divās sistēmās ar atšķirīgu piekļuves modeli.

Ikdienā šī robeža izpaužas ļoti skaidri. Piemēram, līguma statuss, atbildīgais un termiņš tiek uzturēti Dynamics 365 ierakstā, bet pats līguma fails atrodas bibliotēkā. Lietotājs atver lietu no Dynamics, redz pareizo dokumentu un to rediģē SharePoint pusē, nevis eksportē uz lokālu disku un atgriež atpakaļ ar citu faila nosaukumu. Tieši šeit rodas drošības ieguvums: piekļuve dokumentam ir sasaistīta ar lietas kontekstu, nevis ar nejaušu mapju struktūru.

Ko ar to darīt praktiski:

• definēt, kuri lauki ir procesa dati un kuri ir dokumenta metadati;
• SharePoint bibliotēkā glabāt failu, nevis procesu statusus;
• Dynamics 365 ierakstā izmantot saiti vai dokumentu integrācijas punktu, nevis failu kopijas;
• pieeju balstīt uz lietas un dokumenta lomu, nevis uz vienu kopīgu mapes atļauju slāni.

Rezultātā lietotāji strādā vienā procesa skatā, bet dokumentu dzīves cikls paliek tur, kur tam jābūt — SharePoint. Tas ir pamats pārējam integrācijas dizainam, jo bez šīs robežas meklēšana, piekļuve un audita pēdas sāk konfliktēt. Tālāk svarīgi ir sakārtot bibliotēku tā, lai meklēšana atrod saturu, nevis tikai faila nosaukumu.

Kā konfigurēt dokumentu bibliotēkas, lai meklēšana atrod saturu, nevis faila nosaukumu

Praksē problēma parādās brīdī, kad lietotājs atceras nevis faila nosaukumu, bet līguma numuru, klientu vai frāzi dokumentā. Ja bibliotēka ir konfigurēta tikai kā failu noliktava, meklēšana atrod mapes nosaukumu vai pēdējo saglabāto failu, nevis pašu saturu. Vienā projektā tas izpaudās ļoti tipiski: dokumenti bija augšupielādēti pareizi, bet lietotāji tos meklēja pēc biznesa datiem, kas dokumentā bija iestrādāti tikai kā teksts. Pēc tam nācās sakārtot bibliotēkas metadatus un meklēšanas lauku lietojumu.

Kas tika mainīts praksē:

• katram dokumentam piesaistīja skaidrus kolonnas laukus, kas atkārto biznesa identifikatoru;
• bibliotēkas skatos atstāja tos laukus, pēc kuriem lietotājs tiešām filtrē;
• augšupielādes procesā nodrošināja, ka dokumenta īpašības tiek aizpildītas uzreiz, nevis pēc tam manuāli;
• teksta saturā lietoja vienotu faila struktūru, lai meklēšana indeksē konsekventu informāciju.

Microsoft 365 pusē ikdienas darbam tas nozīmē doties uz Document Library → Settings → Versioning settings, pārbaudīt versiju politiku un vienlaikus bibliotēkas kolonnās nodrošināt laukus, ko izmanto filtri un skati. Ja bibliotēka ir sasaistīta ar Dynamics 365 lietu, tad dokumenta nosaukumam nepietiek — vajadzīgs arī klients, lietas tips vai līguma identifikators. Meklēšana tad strādā divos līmeņos: pēc satura un pēc metadatiem.

Rezultāts praksē ir mazāk “es nezinu, kurš no trim failiem ir īstais” un vairāk precīza atlase pēc konteksta. SharePoint un Dynamics 365 kombinācijā tas ir būtiski, jo cilvēks dokumentu atrod no procesa ieraksta, nevis no failu arhīva. Tālāk jāpārbauda, kad šī integrācija apstājas tehniskajās robežās — īpaši on-premises vidē, kur spraudņi, SPN un autentifikācija kļūst par reālu kļūdu avotu.

Kad on-premises risinājumā jāpārbauda spraudņi, SPN un autentifikācija

On-premises vidē integrācijas kļūdas bieži neizskatās pēc drošības problēmas. Lietotājs redz tikai to, ka dokuments neatveras, bibliotēka nesinhronizējas vai serviss atbild lēni. Cēlonis bieži slēpjas spraudņos, autentifikācijā vai nepareizi sagatavotā servisa kontā. Microsoft drošības praksē on-premises vidē uzsver, ka production serveros jāatspējo debugging, un jāuzstāda jaunākie operētājsistēmas un IIS atjauninājumi [2]. Tas nav formāls ieteikums — tieši šie elementi nosaka, vai integrācija darbojas stabilā stāvoklī.

Rīcības secība konsultanta darbā izskatās šādi:

1. pārbauda, vai problēma parādās tikai integrācijas ceļā vai arī pašā Dynamics 365 vidē;
2. pārskata, vai serverī nav aktīvu spraudņu, kas palēnina pieprasījumu un bloķē plūsmu;
3. pārbauda service account un SPN, īpaši, ja tiek lietots domēna lietotāja konts; SPN nosaka savstarpējo autentifikāciju starp klientu un serveri [2];
4. salīdzina, vai application un deployment web services nav nokonfigurēti ar konfliktojošu identitāti;
5. pārbauda, vai web farm scenārijā kernel-mode authentication paliek ieslēgts, kā iesaka Microsoft [2].

Ja integrācijas serverī darbojas gan application, gan deployment web services un kernel-mode authentication ir atspējots, abus servisus konfigurē zem viena domēna lietotāja konta, lai novērstu duplicate SPN issues [2]. Ja deployment lomai nepieciešams provisionēt organizations Customer Engagement datubāzē, tai jābūt ar paaugstinātām atļaujām [2]. Šeit svarīga ir pārbaude praktiskā līmenī: pēc izmaiņām autentifikācijai jānotiek bez pārlēkšanas uz anonīmu vai kļūdas stāvokli, bet servisa pieprasījumiem jāatgriežas ar paredzamu identitāti.

Ja šos punktus izlaiž, integrācija sāk uzvesties nepastāvīgi: vienu dienu strādā, nākamajā pārstāj sinhronizēt dokumentus vai piekļūt bibliotēkai. Tāpēc šajā posmā svarīgākais nav tikai “salabot kļūdu”, bet uzlikt stabilu autentifikācijas modeli. No turienes loģiski pāriet uz integrācijas scenāriju, kur SharePoint un Dynamics 365 darbojas kopā, bet nesāk cīnīties par vienu un to pašu procesu.

Integrācijas scenārijs, kur SharePoint un Dynamics 365 nenonāk viens otram pa ceļam

Tipiska kļūda praksē ir mēģinājums padarīt SharePoint par otro Dynamics 365 kopiju. Komanda sāk sinhronizēt visus statusus, pārdēvējumus un piešķīrējus abos virzienos, un pēc dažām nedēļām rodas konflikts: viens lietotājs dokumentu pārvieto bibliotēkā, otrs tajā pašā brīdī maina lietas statusu Dynamics 365 pusē. Kāpēc tas notiek? Tāpēc, ka abām sistēmām tiek piešķirta viena un tā pati loma — gan dokumentu glabāšana, gan procesa vadība. Tad integrācija sāk traucēt pati sev.

Pareizā konfigurācija sākas ar skaidru sadalījumu. SharePoint glabā dokumentu, versijas un sadarbības darbu. Dynamics 365 glabā lietas kontekstu, atbildīgo, posmu un biznesa loģiku. Integrācijas punkts ir saite vai dokumentu sasaiste, nevis divpusēja kopēšana katram lauka izmaiņu notikumam. Praktiski tas nozīmē, ka:

• dokumenti tiek atvērti no lietas ieraksta, nevis no atsevišķas mapes shēmas;
• lietotājs maina statusu Dynamics 365, bet ne tikai tāpēc dokumenta faila nosaukumu SharePoint pusē;
• SharePoint pusē notiek faila rediģēšana un versiju veidošana;
• Dynamics 365 pusē tiek uzturēti tikai tie lauki, kas nepieciešami procesam.

Šis scenārijs darbojas īpaši labi, ja integrācija ir minimāla un konsekventa: viens avots procesu datiem, viens avots dokumentiem. Ja to neizlabo, rodas dublēti nosaukumi, nesakritīgi statusi un grūtības auditā, jo vairs nav skaidrs, kura sistēma ir patiesais avots. Tieši tāpēc konsultanta darbā labāk ir apzināti samazināt integrācijas apjomu, nevis mēģināt abas platformas savīt vienā lielā replika risinājumā. No šejienes raksta loģika aizved pie kopējā secinājuma par robežām un pārvaldību.

Avoti

Kā KSJ var palīdzēt