Triển khai Microsoft Dynamics CRM 4.0

Đăng bởi: / Ngày : February 22, 2021

Nếu bạn chỉ nghĩ dùng CRM như là một công cụ quản lý sale và marketing thì hãy nghĩ lại đi. Microsoft Dynamics Customer Relationship Management là một platform cho các ứng dụng phát triển quản lý và theo dấu thông tin và quá trình liên quan đến các đối tượng real-world.
Những đối tượng này có thể là khách hàng, nhưng cũng có thể chỉ là những thực thể nhỏ (và liên quan đến các hoạt động) mà bạn cần quản lý.

Như là một giải pháp tuỳ chỉnh có qui mô lớn, có những điều cơ bản liên quan đến khiển trai cần được hiểu. Trong bài này, tôi sẽ nói về một số khái niệm cơ bản liên quan đến triển khai Microsoft Dynamics CRM, bao gồm cách sử dụng những khá niệm này để hỗ trợ cho một giải pháp đơn lẻ, và nên hay không nên dùng kiến trúc đa chiếm hữu như thế nào làm một phần của toàn bộ chu kì sống của giải pháp.

Tôi muốn nói rõ hơn về “giải pháp” Microsoft Dynamics CRM nhắc đến ở đầu. Ý tôi là tất cả các tuỳ chỉnh, các phần mở rộng, các coding tuỳ chỉnh, những thay đổi lược đồ, và vâng vâng. Một giải pháp không chỉ là một thứ; nó là toàn bộ các thay đổi gộp lại.

Nói sâu hơn, một giải pháp Microsoft Dynamics CRM là một ứng dụng Web data-driven chuẩn ASP.NET 2.0 và Microsoft .NET Framework 3.5. Hệ thống 3 tier bao gồm những thành phần chính sau:

Data Tier SQL Server 2005 hay cơ sở dữ liệu SQL Server 2008. Sử dụng SQL Server 2008 yêu cầu một fix hot như miêu tả trong bài “Support for Running Microsoft Dynamics CRM 4.0 together with Microsoft SQL Server 2008.”

MiddleTier Microsoft Internet Information Services (IIS) 6.0 hay Web front end sau đó; SQL Server Reporting Services (SRS) 2005 hay SRS 2008; ASP.NET 3.5; Windows Services tuỳ chỉnh.

Client Tier Microsoft Internet Explorer 6.0 hay client sau đó; ASP.NET 2.0 hay sau đó, client Microsoft Office Outlook 2003 hay Office 2007 (với truy cập offline tuỳ ý); những cái khác như các client mobile bên thứ ba và khách hàng

Microsoft Dynamics CRM cũng phụ thuộc vào nhiều dạng hệ thống external bao gồm Microsoft Exchange Server 2003 hay sau đó và Active Directory.

Solution Development Lifecycle

Một giải pháp Microsoft Dynamics CRM có cùng vòng đời mà một project phát triển ứng dụng tuỳ chỉnh có, giống với quá trình như hình 1.

Hình 1 Chu kì phát triển ứng dụng
Toàn bộ quá trình này được hỗ trợ bởi một số môi trường ao gồm phát triển, kiểm tra, và hệ thống sản xuất. Trong thế giới của bất kì ứng dụng doanh nghiệp đa diện nào, thì nó, tất nhiên hoá ra có thể là cực kì phức tạp. Nếu, ví dụ, bạn mirror môi trường của bạn, bạn phải kết thúc giống như hình 2

Hình 2 Mirror môi trường phát triển, thử nghiệm và sản xuất của bạn
Có ba domain, 3 domain controller, 3 server mail, 3 server Web, và 3 server dữ liệu – và model này giả sử là SRS và CRM trên cùng một box, và không tính đến những thứ như tải cân bằng. Bây giờ hãy tưởng tượng bạn add phần thừa và một vài dịch vụ external như Microsoft Office SharePoint Services (MOSS), bạn có thể kết thúc bằng một sơ đồ như hình 3.

Hình 3 Tăng sự phức tạp
Vì lý do tốn kém và phức tạo, trade-offs có thể được xem xét để cân bằng như cầu cô lập môi trường khỏi nhu cầu giảm tốn kém và tăng sự quản lý. Các tổ chức do đó đã xem xét nhiều loại công nghệ khác nhau, như ảo hoá và các chức năng kiến trúc đa chiếm hữu tích hợp Microsoft Dynamics CRM, để giải quyết thách thức này.

Khi thiết kế một nhóm các môi trường để hỗ trợ chu kì sống của dự án CRM của bạn, có một vài suy nghĩ, và tuỳ thuộc vào nguyên tắc nào là quan trọng với bạn, bạn phải chọn để đi hướng này hay hướng kia. Cuối cùng, các nhà thiết kế thúc đẩy cách ly toàn bộ sử dụng chính xác sự sao chép. Họ tin tằng cách duy nhất để công nhận mà cái gì đó sẽ làm việc bên ngoài sản phẩm để có một môi trường kiểm tra hoàn toàn giống 100% với môi trường thật. Mỗi server, mỗi bit, và mỗi cài đặt đều phải chính xác và hoàn toàn cách ly khỏi phát triển và sản xuất cho các tester và IT để chấp nhận và tin rằng nó sẽ làm việc khi thành sản phẩm.

Ngược lại, những người khác nghĩ cách ly không thật sự là vấn đề. Nếu họ có thể, họ sẽ phát triển và kiểm tra trực tiếp trên môi trường sản xuất. Họ xem phần thừa là lãng phí tiền bạc và thời gian, và sẽ đơn giản hơn nếu họ có thể đến đó và làm mọi thứ hoạt động.
Các thành phần của CRM Solution

Các thành phầ của giải pháp Microsoft Dynamics CRM có thể chia làm 4 vùng chính, và giải pháp của bạn có thể chứa một, hai, ba hay cả bốn vùng này.

Customizations: Nó chứa các thay đổi form, khung lưới, sơ đồ, và siêu dữ liệu; các role an ninh, tiến trình công việc, các cài đặt hệ thống, và các template. Các tuỳ chỉnh Microsoft Dynamics CRM được chia thành một hay nhiều (thường là một đến hai) file XML được khoá. Chúng được import vào triển khai CRM thông qua Outlook hay khu vực Web client”Settings | Customization” và sau đó được “publish” để làm chúng active. Tất cả điều này có thể được tự động sử dụng code được viết lên Microsoft Dynamics CRM SDK.

Extensions: Nó có những báo cáo và các code tuỳ chỉnh như các plug-in phải được triển khai tách biệt khỏi customizations. Thông tin đăng kí plug-in được cất giữ thành một fule XML và có thể được triển khai thông qua hoặc là một dòng lệnh hoặc là một ứng dụng Windows do Microsoft cung cấp. Nó cũng có thể tự động hoá thông qua code được viết trên Microsoft Dynamics CRM SDK.

Custom Code: Bất kì thứ gì được phát triển như là một phần của giải pháp của bạn, và nó có thể chứa các dịch vụ Web external, các thành phần ứng dụng Web tuỳ chỉnh, và vâng vâng. Các nguyên tắc và thực hành cho triển khai các code tuỳ chỉnh không có gì khác ứng dụng Web tuỳ chỉnh khác

Data: Bất kì thông tin cầu được import vào một môi trường cho môi trường đó hoạt động. Nó chứa các dữ liệu domain (như một danh sách các code sản xuất) hay người dùng. Dữ liệu mà giải pháp của bạn cần để triển khai vào instance Microsoft Dynamics CRM của bạn dùng các code được script hay chức năng Bulk Import của CRM, hay với một số dạng của quá trình extrnal sử dụng BizTalk hay công cụ ETL(extract, transform, load) khác. Một số dữ liệu, như Users, cần được tạo bằng tay hay thông qua call Microsoft Dynamics CRM SDK

Tôi thích nghĩ triển khai giải pháp CRM chỉ như là khiển trai ứng dụng tuỳ chỉnh phát triển. Điều đó có nghĩa là trong suốt khi phát triển và kiểm tra, mỗi xây dựng mới của giải pháp được cài đặt từ một hệ thống base clean và quá trình có thể lặp lại và cũng có thể script.

Vậy còn Multi-Tenancy?

At first glance, this might appear to be the panacea that solves all of our manageability, isolation, and cost conundrums. Such a solution might be visualized as in Figure 4.
Bây giờ hãy nói đến môi trường mà bạn sẽ triển khai chúng trông như thế nào. Bạn có thể đọc các bài viết về Enterprise Edition của Microsoft Dynamics CRM 4.0 hỗ trợ cho một chức năng gọi là multi-tenancy, , cho phép bạn chia nhiều instance của Microsoft Dynamics CRM trong một triển khai đơn lẻ. Điều đó co nghĩa một vài tổ chức hoàn toàn khác biệt với những báo cáo của riêng nó, tiến trình làm việc, các tuỳ chỉnh và các sơ đồ có thể được chạy trong cùng một set của phần cứng dùng chung các server vật lý và các instance cơ sở dữ liệu và Web sites IIS.

Hình 4 Một giải pháp multi-tenancy-only
Điều này có vẻ hợp lí vì mỗi tổ chức có cơ sở dữ liệu vật lý của riêng nó trên SQL Server hay instance được chia sẻ (bao gồm các tuỳ chỉnh, quá trình làm việc, người dùng, các role, và các cài đặt) và folder SQL Reporting Services của riêng nó

Model này làm hiệu khá hiệu quả nếu những tổ chức khác biệt là một phần của những nhóm hay các giải pháp triển khai khác nhau. Và multi-tenancy được thiết kế cho điều này. Nó cũng đúng là mõi tổ chức (hay người thuê) có cơ sở dữ liệu của riêng mình, tất cả chúng đều chia sẻ cùng một unit tổ chức(OU) và các nhóm Active Directory, và chúng cũng chia sẻ các dịch vụ nền và những ứng dụng đầu cuối. Điều đó có nghĩa là một dịch vụ thiếu đồng bộ và Web site IIS sẽ được chia sẻ giữa những tổ chức. Các server đầu cuối có thể “host” những tổ chức khác nhau thông qua một URL provider xác định, dựa trên URL, những tổ chức nào để host.

Hãy lấy URL này làm ví dụ: crmserver/ContosoDevOrg/loader.aspx and crmserver/ContosoTestOrg/loader.aspx. Server CRM tìm trong directory gốc để xác định tên của tổ chức để phục vụ. Nếu tên gốc của tổ chức không được tìm thấy, như trường hợp của crmserver/loader.aspx, server mặc định cho tổ chức đầu tiên được tạo ra trong triển khai hay cái mà người dùng call đã truy cập.

Vì cùng một Web site được dùng cho hai tổ chức, nếu bạn tuỳ chỉnh code như là một phần của giải pháp của mình, nó sẽ được chia sẻ bởi cả hai tổ chức, ví dụ

crmserver/ContosoDevOrg/ISV/mycustomdialog.aspx

hoặc

crmserver/ContosoTestOrg/ISV/mycustomdialog.aspx.
Cả hai đều point đến cùng một fiel vật lý trên đĩa, như C:\inetpub\wwwroot\isv\mycustomdialog.aspx. Vì phiên bản đó của một extension tuỳ chỉnh sẽ khác nhau giữa Dev, Test, và Production, điều này có thể gây ra một vấn đề nghiêm trọng. Hãy giả sử, ví dụ, Build 11 của ứng dụng của bạn hiện đang được phát triển, còn Build 9 đang ở UAT ( user acceptance testing) để kiểm tra. Nếu bạn cố gắng dùng multi-tenancy để giải quyết vấn đề của môi trường, bạn sẽ phải vất vả cách ly hai build này.Trong trường hợp đó, bạn nên thử dùng giải pháp như hình 5.

Hình 5 Cố gắng dùng các server IIS khác nhau để tách code giải pháp tuỳ chỉnh của bạnTrong model đó (nếu bạn không còn dùng địa chỉ Network Load Balancing), người dùng có thể hit một URL như thế này:

Development 192.168.1.100/ContosoDevOrg/loader.aspx

Test 192.168.1.105/ContosoTestOrg/loader.aspx

Production 192.168.1.110/Contoso/loader.aspx

Model này cho bạn 3 server đầu cuối tách biệt, host ba tổ chức khác nhau, với 3 code khác nhau dựa trên đĩa. Chừng nào người dùng còn không cố ý hit sai tổ chức trên server không đúng, mọi thứ còn ổn thoả.

Không may, vì tất cả các server đầu cuối được xem là một phần của cùng một triển khai, những khó khăn bắt đầu hiện rõ từng chút một mà bạn có thể nhận ra ngay lần đầu. Điều này thật sự là môt thách thức nếu giải pháp của bạn dùng các plug-in hay các quá trình làm việc không đồng bộ, bởi khi bạn có thể kiểm soát server nào mà người dùng của bạn hit, bạn không thể kiểm soát dịch vụ không đồng bộ nào sẽ xử lý các event và các yêu cầu cho tổ chức nào.

Đó là vì tất các dịch vụ không đồng bộ trong công việc triển khai theo cách luân chuyển, và như vậy dịch vụ không đồng bộ của triển khai server có thể xử lý một workflow, công việc cuả hệ thống, hay phản hồi pulg-in không đồng bộ đến một yêu cầu từ server test của bạn, do đó đẩy lùi yêu cầu cách ly. Thêm nữa, nếu code tuỳ chỉnh của bạn được điều khiển bởi quá trình không đồng bộ phụ thuộc vào các file phải được triển khai trên đĩa đến server (như là file cấu hình hay một file trong Global Assembly Cache, hay GAC), bạn sẽ bị xung đột phiên bản.

Cũng quan trọng để chú ý rằng, những vấn đề chỉ nổi lên khi bạn đang viết code tuỳ chỉnh cần được triển khai đĩa trên hay nếu code tuỳ chỉnh của bạn phụ thuộc vào tài nguyên chỉ có sẵn trên hay từ một server cụ thể. Nếu giải pháp của bạn đơn giản và chỉ dùng các tuỳ chỉnh (schemas, forms, views, and so forth), workflows, và report, bạn không cần dùng cách tiếp cận vấn đề nào như hình 4.

Vậy multi-tenancy để làm gì và khi nào thì nó là một giải pháp tốt cho môi trường chu kì sản phẩm. Multi-tenancy ban đầu được thiết kế để giải quyết các vấn đề phần cứng liên quan đến host nhiều người thuê khác biệt trong môi trường sản xuất, và nó rất có hiệu quả. Trước đây, trong Microsoft Dynamics CRM 3.0, mỗi triển khai, hay người dùng, phải dành riêng instiance SQL Server hay SQL Server, cũng như server đầu cuối.

Điều này đúng cho nhiều lý do, bao gồm cả các cài đặt triển khai xác định thường được lưu giữ trong registru và trên đĩa. Tất cả những cấu hình này bây giờ đã được di chuyển đến c�� sở dữ liệu, do đó một server ứng dụng đơn lẻ có thể quản lý nhiều tổ chức. Multi-tenancy tiện dụng cho các phiên bản được host của CRM bao gồm Microsoft Dynamics CRM Online.

Xem xét thiết kế

Bây giờ bạn đã hiểu được những vấn đề tiềm tàng, hãy nói đến những điều mà bạn cần ghi nhớ khi thiết kế triển khai của bạn. Câu trả lời, là còn tuỳ. Nó chắc chắn có thể chạy một môt môi trường CRM đầy đủ (bao gồm domain controller, SQL server, và Web server) trên một box đơn lẻ, như bạn có thể thấy trong phép chứng minh Microsoft Dynamics CRM 4.0 Virtual Machine (xem sidebar “CRM Resources” cho URL). Cũng rất thông thường để dùng một image ảo máy đơn lẻ cho môi trường phát triển. Để kiểm tra, tuy nhiên cũng quan trọng để phê chuẩn những thử thách chính trong môi trường test và vì lý do này, tôi khuyên bạn nên kiểm tra môi trường mirror môi trường sản xuất theo cấu trúc chứ không phải dung tích. Môi trường của bạn có thể giống như hình 6.

Hình 6 Cấu trúc môi trường kiểm tra nên mirror cấu trúc sản xuất.

Trong cách tiếp cận này, bạn nên hạn chế phần cứng vật lý cảu cấu trúc dùng ảo hoá và những nỗ lực hơn nữa để hạn chế ảo hoá tài nguyên bằng các chỉ ảo hoá một số viễn cảnh chủ chổ mà cần được kiểm tra. Bạn sẽ có thể cho phép những người phát triển của bạn phát triển trên một image server đơn lẻ (hay nhiều image, nếu chúng có máy ảo của riêng chúng trên các desktop cá nhân) nếu bạn đảm bảo là bạn sẽ chú ý và nhận thức được môi trường nào mà giải pháp của chúng sẽ được triển khai. Vấn đề những người phát triển nên chú ý cũng là ván đề bạn nên xây dụng môi trường test của mình để phê chuẩn, bao gồm:
Make the Settings Configurable Không ví dụ giả sử server sẽ tương ứng với một localhost hay một cổng xác định.

Be Aware of Multiple Servers Không giả sử mọi việc sẽ làm việc mà không cài đặt proxy người dùng hay trust các uỷ quyền.

Keep Load Balancing in Mind Hãy cẩn thận với tình trạng session và caching. Chú ý rằng Microsoft Dynamics CRM được thiết kế để hoàn thiện stateless và làm việc hiệu qỉa với load balancer luân chuyển.

Think about Multi-Tenancy Khi nhiều tenants được host trên một máy đơn lẻ, chúng chia sẻ cùng một không gian xử lý. Điều đó có nghĩa các thành phần như cache cần được key bằng tên tổ chức để người dùng từ một tổ chức sẽ không tình cờ sử dụng dữ liệu từ những tổ chức khác. Thêm nữa, khi code bên client của bạn đã có link hay call quay lại server, bạn cần đảm bảo là call vẫn giữ nguyên tên tổ chức trong URL; nếu không, bạn có thể hit tổ chức mặc định hay tổ chức mà mình không mong đợi.

Lời khuyên chủ yếu

Cách ly là quan trọng

Khi thiết kế giải pháp của mình, hãy nhớ rằng cách nào tiếp cận (như hình 4,5,6) sẽ hiệu quả nhất cho bạn và nên nhận thức rõ khi nào và ở đây code tuỳ chỉnh của bạn có thể chạy. Cũng không nên lo lắng về những vấn đề này vì dạng mở rộng mà giải pháp bạn dùng

Ảo hoá

Ảo hoá giúp giảm sự phức tạp khi xây dựng một môi trường mirror các viễn cảnh chính của sản phầm. Ở đây cũng có một vài hướng dẫn về cài đặt. Đặt CRM và SQL Server trên những server tách biệt. Điều này giúp bạn xác định trust cho uỷ quyền và những vấn đề liên quan khác. Các server CRM nên là load-balanced, giúp xác định session, caching và những vấn đề cross-server. Cuối cùng, đặt domain controller và email trên những server tách biệt; nó giúp xác định các vấn đề kết nối

Refresh environment cho mỗi build

Như là một nguyên tắc chung, tạo một backup hoặc là của môi trường ảo hay đơn giản của cơ sở dữ liệu Microsoft Dynamics CRM(Data and Config) để sau đó có thể restore để đưa server quay lại tình trạng không có vấn đề. Sau đó bạn cần thực hiện triển khai đầy đủ clean vào môi trường fresh mỗi lần, gồm code tuỳ chỉnh, các tuỳ chỉnh, pug-in và dữ liệu domain.

Redundancy/Performance Testing Can Be Done Separately

Ngoại trừ những tổ chức rất lớn, bạn có thể thường sử dụng test failover và hoạt động thông qua mô phỏng cách ly chứ không phải qua build-outs “real-world”. Điều này có nghĩa là bạn không cần cố gắng xây dựng một môi trường test kích hoạt kiểm tra những viễn cảnh này. Thay thế nó, bạn có thể phụ thuộc vào việc kiểm tra chúng hoặc là trong môi trường sản phảm hay môi trường one-off.

Tóm lại, Microsoft Dynamics CRM là một hệ thống có khả năng thay đổi, dành cho các doanh nghiệp, khi được cấu hình và triển khai thích hơp, có thể quản lý các nhóm nhỏ, các giải pháp rộng trong doanh nghiệp, và các công việc nào giữa hai vấn đề này. Hãy cố gắng xác định môi trường chi kì sản phẩm nào là đúng cho bạn tuỳ vào những nhân tố khác nhau.

Nói chung, multi-tenancy không phải là một các lý tưởng để giải quyết thách thức chu kì phát triển của sản phẩm của những giải pháp phức tạp và được dùng tốt nhất khi bạn hiểu biết nó đầy đủ. Những giải pháp đơn giản cũng cần những tuỳ chỉnh cơ bản hay điều này tận dụng những code thích hợp và cách ly các phần mở rộng tuỳ chỉnh không phụ thuộc vào tài nguyên đĩa hay truy cập server xác định nên theo model trong hình 4.
Nếu giải pháp của bạn cần thêm tài nguyên cách ly, server xác định, hay truy cập (có thể một dịch vụ external chỉ được cho phép thông qua VLAN của bạn từ một server xác định đến một các khác), và vâng vâng, tôi khuyên bạn nên dùng model hình 6. Và các bạn nên khác cách ở hình 5 vì nó dễ hack nhất.

Cuối cùng, Microsoft Dynamics CRM có thể được triển khai trong hàng nghìn cấu hình, và chính xác cái nào phù hợp với bạn thụ phuộc vào việc giải pháp của bạn yêu cầu gì. Hiểu hơn về multi-tenancy, các môi trường triển khai server đơn lẻ, các môi trường kiểm tra ảo, và những viễn cảnh có thể kiểm tra được đều quan trọng với bạn, bạn nên thiết kế một sản phẩm phát triển chu kì sống vừa hiệu quả vừa tiết kiệm.