Phiếu giao nhiệm vụ đồ án tốt nghiệp

trang này chỉ cung cấp một thực đơn "Modify My Page". Tuy nhiên, người dùng này vẫn có thể dùng lựa chọn "Design this Page" và chỉnh sửa Web Parts. Bất kỳ các tùy biến nào sẽ được lưu trữ như là dữ liệu cá nhân trong CSDL Một Web Part Page có các Web Part Zones. Ta thêm một Web Part vào Web Part Page bằng cách đặt nó vào một Web Part Zone. WSS cho phép người sở hữu trang tạo một Web Part Pages mới với một mẫu cho sẵn. Đối với trình duyệt, có thể chọn một trong các mẫu Web Part Page để tạo một Web Part Page với các vùng định sẵn. Nếu dùng Microsoft Office FrontPage 2003 để tạo và thiết kế Web Part Pages thì ta còn linh động hơn bởi vì ta có thể thêm, xóa, chứa các vùng trên Web Part Page bằng cách sử dụng công cụ thiết kế trang của FrontPage. WSS cung cấp một bộ máy hiển thị các Web Part Pages bằng cách mở rộng ASP.NET. WSS định hướng các yêu cầu Web Part Page tới một đối tượng của lớp SharePointHandler — một điều khiển ASP.NET. Điều khiển này định nghĩa trong không gian tên Microsoft.SharePoint.ApplicationRuntime. Với mỗi yêu cầu Web Part Page, đối tượng SharePointHandler có trách nhiệm lấy về tất cả dữ liệu cần thiết từ CSDL nội dung. Đối tượng SharePointHandler cũng phải lấy dữ liệu từ các bảng khác để xét xem các Web Parts có được tùy biến và cá nhân hóa không. Hình vẽ 3.17: Xây dựng một Web Part Page Xây dựng Web Part Với các hiểu biết ban đầu về cơ sở hạ tầng Web Part, ta hãy tạo một Web Parts bằng Visual Studio .NET. Để bắt đầu với công việc phát triển Web Part, ta nên tải xuống và cài đặt Web Part Templates cho Visual Studio .NET. Các mẫu này được phân phối dưới dạng các tệp cài đặt (.msi) có tại các trang phát triển SharePoint. Sau khi đã cài đặt Web Part Templates, Visual Studio .NET cung cấp một mẫu dự án mới để tạo ra các thư viện Web Part dạng DLL. Tạo một Web Part bằng cách đăng ký một lớp kế thừa từ lớp WebPart được định nghĩa trong gói Microsoft.SharePoint.dll. Lớp WebPart tồn tại trong không gian tên Microsoft.SharePoint.WebPartPages. Bạn phải viết đè các phương thức của lớp WebPart để có thể sử dụng các đặc điểm của lớp này. Để tạo ra một lớp "Hello, World" Web Part truyền thống, ta chỉ cần viết đè phương thức RenderWebPart: using Microsoft.SharePoint.WebPartPages; using System.Web.UI; namespace myWebParts { public class myWebPart : WebPart { protected override void RenderWebPart(HtmlTextWriter output) { output.Write("Hello, World"); } } } Hình sau chỉ ra mối quan hệ giữa các lớp Web Part vừa tạo trong một cây phân cấp đối tượng. Lớp WebPart tạo bởi Microsoft WSS kế thừa từ lớp Control tạo bởi ASP.NET. Vì thế Web Part là một kiểu điều khiển đặc biệt của ASP.NET. Hình vẽ 3.18: Một Web Part cũng là một đối tượng ASP.NET Tuy nhiên sự khác nhau chủ yếu giữa Web Part và các điều khiển ASP.NET là khi chuyển code sang dạng HTML. Khi ta đăng ký một điều khiển ASP.NET, ta hiển thị HTML bằng cách ghi đè phương thức Render còn khi đăng ký một Web Part, ta ghi đè phương thức RenderWebPart. Phương thức Render định nghĩa trong lớp WebPart chứa các mã chung để tạo đường viền và tiêu đề cho Web Part. Phương thức RenderWebPart cung cấp thông số HtmlTextWriter có vai trò như phương thức Render. Điều đó có nghĩa là có thể tạo ra HTML cho Web Part trong phương thức RenderWebPart sử dụng cùng một kỹ thuật của điều khiển ASP.NET. Sau đây là một ví dụ phương thức RenderWebPart: override void RenderWebPart(ByVal output As HtmlTextWriter) { // create HTML table with custom attributes output.AddAttribute(HtmlTextWriterAttribute.Cellpadding, "5"); output.AddAttribute(HtmlTextWriterAttribute.Border, "2"); output.RenderBeginTag(HtmlTextWriterTag.Table); // create new row output.RenderBeginTag(HtmlTextWriterTag.Tr); // create new cell output.RenderBeginTag(HtmlTextWriterTag.Td); output.Write("Name:"); output.RenderEndTag(); // // create new cell output.RenderBeginTag(HtmlTextWriterTag.Td); output.Write("Bob Smith"); output.RenderEndTag(); // output.RenderEndTag(); // output.RenderEndTag(); // Cũng giống như các điều khiển ASP.NET, một Web Part có thể chứa các điều khiển con. Ta phải viết đè phương thức CreateChildControls để tạo ra các điều khiển con này. Tùy biến và cá nhân hóa các Web Part Một trong những khía cạnh mạnh mẽ của công nghệ Web Part là khả năng sử dụng dữ liệu tùy biến và cá nhân hóa. Ta chỉ cần thêm các thuộc tính vào lớp Web Part và gắn các thuộc tính này với các thuộc tính đặc biệt được định nghĩa trong WSS. Kỹ thuật này là một ví dụ tiêu biểu cho sức mạnh lập trình mô tả của .NET Framework. Giả sử ta cần viết một Web Part hiển thị báo cáo thời tiết địa phương của người dùng. Bởi vì người dùng ở các vùng khác nhau, nên Web Part này phải được thiết kế đọc được các mã ZIP cá nhân của mỗi người dùng. Điều này được thực hiện bằng cách định nghĩa thuộc tính ZipCode với một tập hợp các thuộc tính. Sự hiện diện này của các thuộc tính trong mã biên dịch thông báo cho WSS biết cách mà bạn muốn giá trị thuộc tính được tùy biến và cá nhân hóa. [XmlRoot(Namespace="AcmeWebParts")] public class WeatherReportWebPart : WebPart { // Web Part property attributes [WebPartStorage(Storage.Personal), DefaultValue(""), Browsable(true), FriendlyName("Zip Code"), Category("User Info")] public string ZipCode { get { return _ZipCode; } set { _ZipCode = value; } } // field used as backing store for ZipCode property protected string _ZipCode = string.Empty; } Tìm hiểu lớp WeatherReportWebPart ở trên, Web Part này định nghĩa một thuộc tính ZipCode toàn cục (public) cùng với một trường _ZipCode bảo vệ (protected) để lấy các dữ liệu cá nhân. Thông số lưu trữ của thuộc tính ZipCode này là cá nhân (Storage.Personal), điều này thông báo cho WSS biết để tự động lưu trữ và lấy dữ liệu cá nhân hóa cho thuộc tính này. Khi đối tượng SharePointHandler tạo ra một Web Part từ lớp WeatherReportWebPart, nó kiểm tra xem dữ liệu cá nhân có trong CSDL không. Nếu tìm thấy giá trị thuộc tính ZipCode, nó sẽ gán giá trị này cho thuộc tính ZipCode trong lúc khởi tạo. Khi ta định nghĩa một thuộc tính giống như ZipCode trong Web Part, WSS tự động cung cấp các thành phần giao diện người dùng cho phép người dùng tùy biến các thiết lập cho thuộc tính. Khi người dùng cử dụng lệnh chỉnh sửa Web Part Page. WSS hiển thị một thanh công việc (Task Pane) chứa các Tool Parts bên trái của trình duyệt. Tool Part là một thành phần giao diện người dùng của WSS cho phép người dùng xem và tùy biến các thuộc tính của Web Part. WSS cung cấp các Tool Parts tiêu chuẩn cho phép người dùng tùy biến các thuộc tính Web Part. Nếu bạn không thích giao diện chung của Tool Parts tiêu chuẩn, WSS cho phép bạn xây dựng các ToolPart mới. Công nghệ Web Part là rất mạnh mẽ bởi vì nó cung cấp các thuận lợi đặc biệt để sử dụng các dữ liệu tùy biến và cá nhân hóa. Web site của ta có thể dược tùy biến và cá nhân hóa bởi nhiều người dùng bằng nhiều cách khác nhau. Ta không phải viết code để quản lý mối quan hệ người dùng, hoặc để lưu trữ và sử dụng các dữ liệu cá nhân trong CSDL nội dung, do vậy sẽ có nhiều thời gian hơn tập trung vào công việc chính của mình. Tương tác giữa các Web Part Phần lớn các Web sites và đặc biệt là các Portal đều có một vị trí nào đấy để hiển thị một số lượng lớn các nội dung. Điều này có thể làm nên một niềm hứng thú cho người sử dụng nhưng về lâu dài đây có thể là nguồn tạo ra sự lộn xộn. Các nghiên cứu gần đây về tính tiện dụng khi dùng Web đã chỉ ra rằng khả năng cá nhân hóa là một nhân tố cực kỳ quan trọng để đưa đến sự thành công của các Web sites. Đưa đến cho người dùng các chức năng để xây dựng các khung nhìn mang tính cá nhân chính là một sự khác biệt quan trọng giữa các trang Web thông thường và một siêu Web (chẳng hạn các trang Portal). Các Web sites xây dựng dựa trên SharePoint sẽ đảm bảo rằng các module được tạo ra sẽ có khả năng cá nhân hóa. Nội dung của các trang SharePoint không nhất thiết phụ thuộc vào cơ sở hạ tầng ở bên dưới nhưng khả năng mềm dẻo cũng như độ sâu của các module sẽ giúp cho người xây dựng trang đưa ra các nội dung phong phú nơi mà cách thức hiển thị cũng như cấu trúc được quyết định bởi người dùng cuối. Các SharePoint Web Part là những khối xây dựng nên các trang SharePoint vì chúng hiển thị các dữ liệu trong một vùng cửa sổ của người dùng. Trong phần này ta sẽ đề cập đến cơ chế của việc kết nối các Web Parts và thể hiện cách thức xây dựng hai Web Parts làm việc cùng nhau theo lược đồ master/detail. Mô hình kết nối Hai Web Parts kết nối với nhau được thực thi trong một cặp publisher/subscriber. Bất cứ giá trị thay đổi nào đưa ra bởi Provider đều được phản hồi bởi consumer, mô hình này bao gồm hai thực thể tương tác với nhau: một provider cung cấp và một hoặc nhiều consumer khách hàng. Provider được gọi để thu thập các dữ liệu công cộng của nó và làm cho nó có khả năng đăng ký với người gọi. Consumers được gọi để thu về các dữ liệu hiển thị và dựa vào đó cập nhật các vùng giao diện của nó. Hình sau cung cấp một khung nhìn mức cao của mô hình kết nối này: Hình vẽ 3.19: Khung nhìn mức cao về mô hình kết nối Trong phần này ta chỉ đề cập đến mô hình kết nối ICellProvider/ICellConsumer. Thông thường có một vài cặp giao diện mà các Web Parts có thể thi hành để thực hiện kết nối, hai giao diện đơn giản nhất đó là ICellProvider và ICellConsumer. Một provider Web Part là một Web Part mà thực thi giao diện ICellProvider, mặt khác một consumer Web Part phải thực thi giao diện ICellConsumer. ICellProvider được định nghĩa như sau: public interface ICellProvider { // Events event CellProviderInitEventHandler CellProviderInit; event CellReadyEventHandler CellReady; // Methods void CellConsumerInit(object sender, CellConsumerInitEventArgs cellConsumerInitEventArgs); } Một provider phải chứa mã để sinh ra một cặp các sự kiện tới consumer và chứa đựng mã điều khiển các sự kiện của consumer , giao diện ICellConsumer mang tính đối ngẫu với giao diện ICellProvider và như sau: public interface ICellConsumer { // Events event CellConsumerInitEventHandler CellConsumerInit; // Methods void CellProviderInit(object sender, CellProviderInitEventArgs cellProviderInitArgs); void CellReady(object sender, CellReadyEventArgs cellReadyArgs); } Hai giao diện trên ánh xạ lẫn nhau: mỗi sự kiện phát sinh bởi giao diện này sẽ tìm một phương thức điều khiển trong giao diện kia và ngược lại. Chẳng hạn sự kiện CellReady của ICellProvider theo thiết kế nó sẽ được phát sinh để báo cho consumers biết rằng dữ liệu mới đã có hiệu lực. Vậy thì bằng cách nào mà một consumer có thể được báo tin về điều đó? Vấn đề được giải quyết như sau, cónumer thực thi phương thức CellReady trong giao diện ICellConsumer. Lưu ý ở đây là không có sự tương tác trực tiếp giữa hai Web Part mà có một thành phần trung gian (chính là SharePoint người tạo ra môi trường thực thi) đã đảm bảo việc ánh xạ mỗi sự kiện với phương thức tương ứng theo cả 2 hướng (từ provider đến consumer và ngược lại). Sinh ra các Web Part kết nối Ngoài các giao diện đã kể ở trên, có một vài phương thức phức tạp hơn để các Web Parts tương tác với nhau và chúng được định nghĩa trong lớp cơ sở WebPart. Môi trường mà SharePoint tạo ra sẽ gọi đến các phương thức đó trước khi các Web Part được sinh ra. Sau đây ta sẽ liệt kê ra các bước cơ bản về vòng đời của các Web Parts kết nối: Với mỗi cặp các Web Parts kết nối thì cơ sở hạ tầng Web Parts sẽ gọi phương thức EnsureInterfaces trên provider và consumer. EnsureInterfaces là một phương thức Web Parts có khả năng cài đè, nó cung cấp cơ sở hạ tầng với các thông tin cho mỗi loại giao diện đang được thực thi, một tham chiếu tới Web Part và số lượng tối đa các kết nối được phép. Với mỗi cặp các Web Parts kết nối, cơ sở hạ tầng Web Part gọi phương thức CanRunAt để biết được mỗi Web Parts có thể thi hành từ đâu (từ client và/hoặc từ server dựa trên cấu hình hiện tại). Phương thức PartCommunicationInit được gọi cho provider và sau đó là cho consumer, cả hai Web Part được báo tin rằng kết nối đã được thiết lập và đảm bảo rằng các điều khiển con của chúng đã được thiết lập. Phương thức PartCommunicationInit được gọi cho provider. Phương thức này có thể tùy biến phát sinh ra sự kiện CellProviderInit, nếu phát sinh sự kiện thì nó phải được điều khiển bởi cơ sở hạ tầng Web Part và nhất thiết phải gọi đến phương thức tương ứng trên consumer. Trong sự kiện CellProviderInit, provider cung cấp một đặc tả về các trường mà nó đang xuất bản. Trong phương thức tương ứng, consumer có thể kiểm chứng những loại giữ liệu gì provider sẽ gửi đi. Với những trường không được chấp nhận thì một ngoại lệ sẽ được ném ra. Phương thức PartCommunicationInit cũng được gọi trên consumer và có thể tùy biến phát sinh sự kiện CellConsumerInit. Nếu sự kiện phát sinh, nó sẽ được điều khiển bởi cơ sở hạ tầng Web Part và được phục vụ thông qua phương thức CellConsumerInit của provider. Phương thức PartCommunicationMain được triệu gọi trên provider để đóng gói bất cứ dữ liệu công cộng nào và báo tin cho consumer thông qua sự kiện CellReady. Một lần nữa sự kiện được nắm bắt bởi cơ sở hạ tầng bên dưới và được điều khiển thông qua phương thức CellReady của consumer. Đoạn mã chương trình sau cho thấy một sự thi hành đặc thù của phương thức PartCommunicationMain trên một Web Part provider. Trong ví dụ này ta đề cập đến một Web Part có tên là EmployeeViewer, nó hiển thị một thuộc tính integer – EmployeeID. Theo đoạn mã này thì Web Part xuất ra ID của nhân viên hiện tại đã được lựa chọn. public override void PartCommunicationMain() { if (CellReady != null) { CellReadyEventArgs cellReadyArgs = new CellReadyEventArgs(); cellReadyArgs.Cell = _employeeID; CellReady(this, cellReadyArgs); } } Đoạn mã sau chứa sự phản hồi thông thường của consumer cho sự kiện CellReady: public void CellReady(object sender, CellReadyEventArgs cellReadyArgs) { if(cellReadyArgs.Cell != null) { _employeeID = (int) cellReadyArgs.Cell; } } Consumer lưu trữ dữ liệu hợp quy cách vào một biến cục bộ cho việc sử dụng sau này. Khi tất cả các bước trên đã hoàn thành, sự kiện OnPreRender được phát sinh trên tất cả các Web Parts cũng như các điều khiển của chúng. Lưu ý quan trọng ở đây là tất cả các phương thức và sự kiện được liệt kê ở trên thì chỉ sự kiện CellReady của provider và phương thức CellReady của consumer là thực sự cần thiết. Thi hành Provider Trước hết ta tạo ra một Project Web Part từ Visual Studio .NET, sau đó tạo các Web Part provider và consumer bằng cách thêm vào Project đang xây dựng: Hình vẽ 3.20: Chọn Provider Web Part Trình winzard sẽ tự động tạo ra một lớp Web Part mới đã thực thi các giao diện ICellProvider và ICellConsumer. Mục đích của ta ở đây là tạo ra một EmployeeViewer Web Part mà hiển thị một vài thông tin cá nhân của một nhân viên đã được định sẵn. ID của nhân viên là một thuộc tính công cộng của Web Part và được định nghĩa các vùng thuộc tính như sau: [Browsable(true), Category("Miscellaneous"), Description("The ID of the selected employee"), DefaultValue(1), FriendlyName("EmployeeID"), WebPartStorageAttribute(Storage.Personal)] public int EmployeeID { get {return _employeeID;} set {_employeeID = value;} } Như đã nói ở trên, trong sự kiện CellReady ta đã đóng gói dữ liệu của nó và chuyển cho consumer; với khả năng có thể hiển thị và cá nhân hóa thì các thuộc tính cũng hiển thị trên thanh editing box chuẩn của Web Part như hình sau: Hình vẽ 3.21: Thay đổi thuộc tính Employee ID Việc dịch mã của Web Part sẽ thi hành các truy vấn dựa vào SQL Server, nắm lấy các thông tin cá nhân về các đặc trưng người dùng như employee ID và đưa ra một bảng hiển thị HTML để hiển thị thông tin, ở đây để làm ví dụ ta có thể chọn cơ sở dữ liệu Northwind. Thi hành Consumer Viết một consumer Web Part không khó hơn việc thiết lập một provider. Ta lặp lại cùng các bước ở trên để thêm vào một consumer Web Part cho dự án. Nếu cả hai Web part chứa trong cùng một Asembly ta cần tạo ra một DWP file thứ hai. Trong trường hợp đơn giản nhất ta chỉ cần cài đè phương thức ảo CellReady và thu về bất cứ giá trị nào mà provider cung cấp và cất dữ các giá trị đó. Phương thức CellReady thu về một đối tượng CellReadyEventArgs mà trong nó có chứa thuộc tính Cell chỉ đến bất cứ giá trị nào mà provider đã cung cấp trong một tham số đối tượng tương tự trong phương thức PartCommunicationMain của nó. Thuộc tính Cell có kiểu object, ta cần ép kiểu để chuyển nó về dạng dữ liệu phù hợp trước khi sử dụng. Consumer cũng có thể muốn kiểm tra xem dữ liệu mà provider đưa ra có hợp khuôn dạng hay không, để làm điều này ta cần thực thi phương thức CellProviderInit. Lưu ý ở đây là phương thức này không thể bị bỏ quên vì nó là một phần của giao diện ICellConsumer. public void CellProviderInit(object sender, CellProviderInitEventArgs cellProviderInitArgs) { if (cellProviderInitArgs.FieldName != "EmployeeID") { throw new NotSupportedException(); } } Ở đây lớp CellProviderInitEventArgs đã được điền đầy dữ liệu bởi provider khi provider phát sinh sự kiện CellProviderInit. Sau đây là một đoạn mã chuẩn để làm điều này: public override void PartCommunicationInit() { if (CellProviderInit != null) { CellProviderInitEventArgs cellProviderInitArgs; cellProviderInitArgs = new CellProviderInitEventArgs(); cellProviderInitArgs.FieldName = "EmployeeID"; cellProviderInitArgs.FieldDisplayName = "Employee ID"; CellProviderInit(this, cellProviderInitArgs); } } Thuộc tính FieldName cho biết tên của đối tượng dữ liệu đang được chuyển giao, dữ liệu này không có cú pháp chính xác – nó có thể là bất cứ thứ gì. Sau đây là một consumer Web Part đơn giản đọc employee ID thông qua kết nối với provider và hiển thị tất cả các hàng được cung cấp trong thuộc tính year tương ứng. year là một thuộc tính của Web Part mà ta tạo ra, nó là một thuộc tính công cộng và có thể hiển thị được, ta định nghĩa nó như sau: [Browsable(true), Category("Miscellaneous"), Description("Year of selected orders"), DefaultValue(1997), FriendlyName("Year"), WebPartStorageAttribute(Storage.Personal)] public int Year { get {return _year;} set {_year = value;} } Employee ID và year là hai tham số được sử dụng trong truy vấn SQL mà kết quả truy vấn được hiển thị thông qua một DataGrid đã được thiết lập để trình bày dữ liệu. private void BuildUI(HtmlTextWriter writer) { DataGrid _grid = new DataGrid(); _grid.AutoGenerateColumns = true; _grid.Font.Name = "verdana"; _grid.Font.Size = FontUnit.Point(8); _grid.HeaderStyle.Font.Bold = true; _grid.HeaderStyle.BackColor = Color.PaleTurquoise; _grid.HeaderStyle.HorizontalAlign = HorizontalAlign.Center; _grid.DataSource = _data; _grid.DataBind(); _grid.RenderControl(writer); } Hình sau cho thấy hai Web Part làm việc cùng nhau trong một Web Page. Hai Web Part đã được kết nối với nhau Thiết lập kết nối Ở phần trên ta đã trình bày cách viết một provider và consumer, các hàm giao diện làm cho chúng làm việc cùng nhau. Để thiết lập môt kết nối giữa hai Web Part theo cách thông thường, ta thiết lập trang Web ở chế độ design và kích vào menu Web Part của Provider (hoặc consumer). Sau đó lựa chọn menu thả xuống Connections và làm theo các chỉ dẫn sau đó, hình sau minh họa điều đó: Hình vẽ 3.22: Hai Web Part đang kết nối với nhau Một số mô hình kết nối khác Sự kết nối giữa hai Web Part dựa trên một cặp giao diện phản chiếu lẫn nhau; tồn tại một môi trường trung gian ở giữa có trách nhiệm gọi các phương thức ở hai bên một cách thích hợp. Các giao diện kết nối khác dành cho việc chu chuyển các dữ liệu được liệt kê ở bảng sau: Giao diện Ý nghĩa ICellProvider, ICellConsumer Dùng để trao đổi các giá trị đơn giữa các Web Part IRowProvider, IRowConsumer Dùng để trao đổi một dòng thông tin đơn giữa các Web Part IListProvider, IListConsumer Trao đổi một danh sách các dữ liệu IFilterProvider, IFilterConsumer Lọc qua các biểu thức mà chứa một hoặc nhiều cặp tên cột và giá trị Bảng 3.5: Các cặp giao diện provider/consumer thông dụng Thông thường, một Web Part mà thi hành giao diện consumer có thể kết nối tới và nhận các dữ liệu từ một Web Part mà thi hành một giao diện provider tương thích. Các giao diện tương thích và bổ sung được liệt kê ở bảng trên. Tất cả giao diện ở bảng 1 có thể kết nối tới mỗi giao diện khác trong một trình duyệt. Tuy nhiên có hai cặp giao diện khác nữa mà ta có thể sử dụng để kết nối các Web Part trong FrontPage 2003 nhưng không phải trong trình duyệt, bảng sau sẽ liệt kê hai cặp giao diện đó: Interfaces Description IParametersOutProvider, IParametersOutConsumer Giao diện provider định nghĩa ra một tập các tham số mà nó có thể gửi cho consumer IParametersInProvider, IParametersInConsumer Giao diện consumer định nghĩa một tập các tham số mà nó có thể nhận được từ Provider Bảng 3.6: Các giao diện chỉ dùng cho FrontPage 2003 Sự khác biệt giữa các cặp giao diện IParametersOut và IParametersIn là một sự tinh tế. Một mặt, provider định nghĩa ra các tham số cái mà được chuyển giao cho consumer. Mặt khác consumer định nghĩa ra những tham số nào sẽ được thu về. Thông thường consumer thể hiện vai trò bị động so với provider. Có thể xảy ra trường hợp một provider không thể kết nối tới một consumer thích hợp được. Để giải quyết vấn đề đó, cơ sở hạ tần Web Part cung cấp một vài biến thể khác để cho phép các Web Part có thể kết nối được với nhau ngay cả khi các giao diện của chúng không khớp với nhau. Các biến thể được liệt kê như sau: Biến thể Cách thức hoạt động IRowProvider to ICellConsumer Một hộp thoại xuất hiện cho phép ta lựa chọn những ô nào bên trong hàng chuẩn bị được ánh xạ IRowProvider to IFilterConsumer Một hộp thoại xuất hiện để ép buộc consumer lựa chọn một cột đơn trong hàng để lọc các thông tin IParametersOutProvider to IParametersInConsumer Một hộp thoại xuất hiện để người dùng định nghĩa ra cách thức mà các tham số từ provider có thể ánh xạ tới các tham số của consumer. (Không có khả năng kết nối trong trình duyệt) IRowProvider to IParametersInConsumer Một hộp thoại xuất hiện chỉ dẫn cho người dùng ánh xạ những cột nào ở trong hàng tới các tham số của consumer. (Không có khả năng kết nối trong trình duyệt) Bảng 3.7: Các giao diện biến thể bên trong Một số mô hình kết nối khác cho phép kết nối hai Web Part ở hai trang khác biệt. Bảng sau liệt kê các giao diện có thể thực hiện kết nối xuyên qua các trang: Trong trang nguồn Trong trang đích IRowProvider IFilterConsumer IRowProvider IParametersInConsumer IFilterProvider IFilterConsumer IParametersOutProvider IParametersInConsumer IParametersInProvider IParametersInConsumer Bảng 3.8: Các giao diện hỗ trợ các kịch bản kết nối xuyên trang Trang nguồn phải chứa đựng một provider Web Part thực thi tất cả các giao diện liệt kê ở cột bên phải của bảng trên. Mặt khác trang đích phải chứa một Web Part thực thi các giao diện tương ứng được liệt kê ở cột thứ hai của bảng trên. Như vậy Khả năng kết nối các Web Part đưa thêm tính linh động cũng như sức mạnh đến cho công nghệ Share Point lên một mức mới. Các Web Part có khả năng kết nối cũng tương tự như các Web Part thông thường ngoại trừ việc chúng thực thi các giao diện đặc biệt mà cho phép chúng “nói chuyện” được với các Web Part tại thời điểm thực thi. Kết chương: chương này đã trình bày khá chi tiết về công nghệ SharePoint, bao gồm: Windows SharePoint Services, SharePoint Portal Server, công nghệ lập trình Web Parts. Có thể nói Windows Server 2003, SQL Server, SharePoint và MS Office đi với nhau sẽ tạo thành một hệ thống cực kì mạnh mẽ, có thể phát triển những ứng dụng (về Portal nói riêng) có quy mô lớn. Đặc biệt SharePoint rất phù hợp với bài toán về cổng nội bộ quản lý doanh nghiệp vì SharePoint hướng đến một nền cộng tác rất cao. Chương sau sẽ trình bày việc ứng dụng SharePoint để xây dựng ứng dụng này. Xây dựng Cổng thông tin nội bộ quản lý doanh nghiệp với công nghệ SharePoint của Microsof Đặc tả yêu cầu người dùng Hệ thống cần xây dựng đó là một cổng thông tin nội bộ dùng cho doanh nghiệp, hệ thống nhằm hướng đến việc giải quyết một số thủ tục hành chính trong công ty như xử lý công văn đến, xử lý công văn đi nhằm giảm thiểu các loại văn bản giấy tờ có thể có… đồng thời cung cấp một số dịch vụ mà người dùng có thể khai thác, chẳng hạn các dịch vụ tìm kiếm thông tin, dịch vụ đăng tải thông tin, tùy biến cá nhân hóa… Hệ thống xây dựng cũng nhằm hướng đến việc trao đổi, chia sẻ thông tin giữa các thành viên trong công ty trở nên dễ dàng hơn, giúp cho họ cập nhật được thông tin một cách dễ dàng, nhanh chóng và chính xác, từ đó góp phần nâng cao năng suất và chất lượng công việc. Các thành viên trong công ty có thể làm việc với nhau trên các tài liệu bằng cách tạo ra các nhóm thảo luận dựa trên các thư viện tài liệu; họ cũng dễ dàng tạo ra các nội dung bằng cách sử dụng MS Office và lưu nó các thư mục công cộng trên Portal để các thành viên khác có thể tham khảo và học hỏi. Hệ thống được tích hợp với phần mềm Outlook của MS nên việc chuyển tải thông tin giữa các thành viên diễn ra nhanh chóng và thuận lợi, đồng thời dịch vụ cảnh báo sẽ giúp cho họ nhận ra những thay đổi sớm nhất phù hợp với họ. Các dịch vụ về quản lý công văn giúp lưu trữ các loại công văn một cách khoa học, việc tìm kiếm, thêm xóa các loại công văn cũng diễn ra thuận lợi dễ dàng. Ngoài ra dịch vụ “đặt cơm trưa” sẽ giúp quản lý việc đặt cơm trưa, dịch vụ “bảng chấm công” sẽ giúp quản lý việc đi làm hay nghỉ việc của các thành viên trong công ty… Trong phần này ta sẽ đặc tả các yêu cầu người dùng dưới dạng các U-Case, các U-Case này được vạch ra trên cơ sở tài liệu đặc tả yêu cầu người dùng đã có nhờ quá trình trao đổi với khách hàng cũng như quá trình khảo sát hệ thống cũ và những yêu cầu đối với hệ thống mới mà tài liệu đặc tả yêu cầu trong khuôn khổ của ĐATN không thể nêu chi tiết. Hình sau mô tả cấu trúc phân cấp của hệ thống Portal cần xây dựng: Cổng nội bộ Tin tức – Sự kiện Tin quốc tế Tin trong nước Tin nội bộ công ty Giới thiệu công ty Cơ cấu tổ chức Các gương mặt trong công ty Lãnh đạo công ty Nhân viên Các quy định và biểu mẫu Danh bạ nội bộ Các quy chế Các văn bản pháp quy Thư viện tài liệu Dịch vụ Tìm kiếm thông tin Xử lý công văn đến Xử lý công văn đi Quản trị nội dung Lịch làm việc Đăng tải nội dung Vui chơi – Giải trí Tích hợp ứng dụng Hỏi đáp – Góp ý Câu lạc bộ Bình chọn ảnh Chúc mừng sinh nhật Chấm công Hình vẽ 4.1: Bản đồ trang của hệ thống Yêu cầu đối với một số chức năng được cụ thể hóa như sau: Xử lý công văn đến Tiếp nhận công văn đến Lưu đồ: - Trong ngày - Văn thư - Bảo vệ Đóng dấu công văn đến và dập mã code - Trong ngày - Văn thư Nhập dữ liệu công văn đến vào Portal - Văn thư - Trong ngày hoặc sau 1 ngày - Văn thư Nội dung công văn đến được cập nhật hàng ngày Lưu công văn đến theo mã code tại bộ phận hành chính Các cá nhân truy cập vào Portal và xử lý các Công văn có liên quan -Ban Giám đốc / Trưởng bộ phận / Phòng ban Kết thúc - Trong ngày hoặc sau 1 ngày Đã xử lý Chưa xử lý Yêu cầu văn thư chuyển công văn đến để xem xét giải quyết - Ngay khi có chỉ định của Lãnh đạo - Văn thư - Cá nhân chịu trách nhiệm -Ban giám đốc/ Trưởng bộ phận/ Phòng ban - Trong ngày Thông báo cho văn thư lấy công văn đến (bản gốc) để lưu trữ Bảng phân đoạn công việc: Stt Công việc Người thưc hiện 1 Tiếp nhận công văn đến Văn thư Bảo vệ 2 Phân loại tài liệu, đóng dấu đến, dập mã code Văn thư 3 Nhập dữ liệu công văn đến vào Portal Văn thư 4 Nội dung công văn đến được cập nhật hàng ngày. Văn thư 5 Tổng giám đốc, Trưởng bộ phận và các cán bộ truy cập vào Porrtal phần quản lý công văn để theo dõi nội dung các công văn được gửi đến và giải quyết các việc theo trách nhiệm của bộ phận Cán bộ chuyên trách 6 Cán bộ chuyên trách yêu cầu văn thư chuyển công văn đến để xem xét giải quyết. TGD Trưởng bộ phận Cán bộ chuyên trách Văn thư 7 Cán bộ chuyên trách thông báo cho văn thư đến lấy công văn (bản gốc) để lưu trữ Cán bộ chuyên trách 8 Lưu lại bản gốc theo đúng mã code đã quy định Văn thư Bảng 4.1: Bảng phân đoạn công việc cho “Xử lý công văn đến” Xử lý công văn đi Các yêu cầu đối với chức năng xử lý công văn đi được cụ thể hóa như sau: Lưu đồ: - Cán bộ được ủy quyền Ngay khi có ý kiến chỉ đạo của Lãnh đạo Công ty hoặc Trưởng bộ phận Dự thảo công văn Không duyệt Duyệt nội dung, ký nháy Trong ngày hoặc sau 1-2 ngày - Trưởng phòng - Trưởng bộ phận Trong ngày hoặc sau 1-2 ngày Duyệt Trình duyệt & ký - Lãnh đạoCông ty Văn thư nhận bản mềm của công văn đi để lưu dữ liệu vào Portal và ghi số công văn - Văn thư - Cán bộ được ủy quyền - Văn thư - Cán bộ được ủy quyền Đóng dấu Lưu công văn theo mã code Gửi công văn đi Sau khi nhận được công văn đã được lãnh đạo Công ty duyệt Sau khi nhận được công văn đã được lãnh đạo công ty duyệt - Văn thư Bảng phân đoạn công việc: Stt Công việc Người thưc hiện 1 Dự thảo Quyết định, công văn, thư mời Cán bộ chuyên trách 2 Kiểm tra nội dung công văn đi, Quyết định, thư mời cả về nội dung và hình thức trình bày công văn. Ký nháy xác nhận. Trình duyệt lên TGĐ Trưởng bộ phận 3 Phê duyệt công văn đi, ký tên. TGĐ 4 Sau khi được duyệt, văn thư yêu cầu cán bộ chuyên trách chuyển bản mềm dự thảo của công văn thông qua Portal. Văn thư ghi số công văn đi. Văn thư 5 Đóng dấu Văn thư 6 Dập mã code và lưu 01 bản công văn gốc đã được đóng dấu tại phòng HCQT Văn thư 7 Bản mềm được lưu dưới dạng file đính kèm trên phần quản lý công văn của Portal Văn thư 8 Thực hiện gửi công văn đi Văn thư Cán bộ chuyên trách Bảng 4.2: Bảng phân đoạn công việc cho “Xử lý công văn đi” Đặt cơm trưa Người dùng vào trang đặt cơm trưa để đăng ký cơm trưa Cho phép các thay đổi về đăng kí cơm trước 11 giờ Hệ thống tự nhận biết người dùng đăng ký, không phải nhập lại tên và mật khẩu Hệ thống tự động nhận biết và quản lý về thời gian (chẳng hạn ngày giờ đăng ký cơm) và sẽ tính tổng số tiền ăn của tháng đó Chỉ áp dụng cho từng tháng một Bảng chấm công Cho phép nhân viên phòng hành chính kiểm soát số ngày công của mỗi nhân viên. Hệ thống phải nhận ra người dùng thích hợp mới có quyền chỉnh sửa nội dung trong phần này (cụ thể là chỉ có nhân viên hành chính hoặc người quản trị nội dung, quản trị Web mới có quyền thay đổi, chỉnh sửa các nội dung) Chỉ áp dụng cho từng tháng một Tìm kiếm Hình vẽ 4.2: các U-case tìm kiếm Xử lý công văn đến Hình vẽ 4.3: Các U-case trong xử lý công văn đến Xử lý công văn đi Hình vẽ 4.4: Các U-case trong xử lý công văn đi Bình chọn ảnh Hình vẽ 4.5: Các U-case trong bình chọn ảnh Chúc mừng sinh nhật Hình vẽ 4.6: Các U-case chúc mừng sinh nhật Đặt cơm trưa Phân tích hệ thống Sau đây ta sẽ mô tả một số U-Case chính ở trên về các mặt như: tác nhân sử dụng, các dòng chính, dòng thay thế, các điều kiện để thực hiện … Chọn cách tìm kiếm Để người dùng tìm kiếm các thông tin cần thiết Tác nhân: người dùng hệ thống Tiền điều kiện: người dùng đã đăng nhập vào Portal Dòng chính: Người dùng chọn một cách để tìm kiếm thông tin, có thể là: Tìm kiếm tất cả Tìm kiếm Lists Tìm kiếm List Items Tìm kiếm Documents Tìm kiếm theo từ khóa Dòng thay thế: Người dùng không chọn một cách tìm kiếm nào cả: Mặc định là tìm kiếm tất cả Chọn miền tìm kiếm Để người dùng tìm kiếm trong một phạm vi nào đó Tác nhân: người dùng Portal Tiền điều kiện: người dùng đã vào dịch vụ tìm kiếm Dòng chính: Người dùng lựa chọn vùng tìm kiếm, có thể là: Tìm kiếm trong tất cả các vùng Tìm kiếm trong Sub Sites Tìm kiếm trong Top Level sites Dòng thay thế: Người dùng không lựa chọn vùng tìm kiếm: Mặc định là tìm kiếm mọi vùng Xem kết quả tìm kiếm Để người dùng thu nhận các thông tin mà họ cần Tác nhân: người dùng hệ thống Tiền điều kiện: người dùng vào dịch vụ tìm kiếm Dòng chính: Người dùng chọn một cách để xem kết quả, có thể là: By site By Author By Date By Areal Simple List Nhấn nút thực hiện tìm kiếm để xem kết quả Dòng thay thế: Nếu người dùng không chọn cách để xem thì hiển thị kết quả theo site Đăng nhập Uses case này ứng với trường hợp người dùng đăng nhập vào hệ thống Các tác nhân: văn thư, cán bộ chuyên trách, trưởng bộ phận, tổng giám đốc và người dùng trong công ty Tiền điều kiện: người dùng phải có một tài khoản Windows và đã được WSS lưu trong cơ sở dữ liệu cấu hình của nó. Dòng chính: Bước 1: người dùng nhập tên và mật khẩu Bước 2: người dùng nhấn đăng nhập Bước 3: hệ thống kiểm tra tên và mật khẩu trong CSDL Nếu đã có tài khoản này thì chuyển sang bước 4 Nếu không có tài khoản này thì chuyển sang bước 5 Bước 4: người dùng đăng nhập vào hệ thống Bước 5: thông báo sai tài khoản Dòng thay thế: không Nhập mã công văn đến vào Portal Uses case này cho phép văn thư nhập mã công văn đến, nơi gửi, người nhận vào phần lưu trữ công văn trên Portal Tác nhân: văn thư Tiền điều kiện: Người dùng phải truy nhập thành công vào Portal với đặc quyền của văn thư Dòng chính: Bước 1: văn thư vào phần lưu trữ thông tin công văn đến trên Portal Bước 2: thêm một dòng mới vào danh sách các công văn đến Bước 3: thêm các thông tin cần thiết (mã công văn, nơi gửi, người nhận… vào dòng thông tin vừa tạo ra ở bước 3 Bước 4: ghi nhận các thay đổi nếu có nhu cầu nhập tiếp bản ghi thì về bước 1 nếu muốn thoát thì quay về bước 5 Bước 5: quay về trang công văn đến Dòng thay thế: Khi văn thư nhập mã công văn trùng với mã công văn đã có trước đó: Đưa ra thông báo lỗi Sửa lỗi: Xóa dòng lưu trữ thông tin Sửa đổi mã công văn Thông báo cho người có thẩm quyền giải quyết công văn đến Use case này áp dụng cho văn thư để thông báo cho người có thẩm quyền giải quyết công văn đến Tác nhân: văn thư Tiền điều kiện: người dùng đã đăng nhập thành công vào Portal với đặc quyền của văn thư Dòng chính: Bước 1: văn thư chọn một hoặc nhiều dòng thông tin công văn đến Bước 2: chọn người có thẩm quyền phù hợp để gửi thông báo Bước 3: Gửi thông báo Bước 4: Quay về trang công văn đến Dòng thay thế: Khi chọn nhầm một dòng thông tin Cho phép chọn lại Khi chọn nhầm người để gửi: Cho phép chọn lại Hậu điều kiện: thông tin phải đến được người có thẩm quyền giải quyết Văn thư nhận thông báo từ nơi khác gửi đến Để nhận các thông báo từ các nơi khác gửi tới, chẳng hạn từ lãnh đạo công ty, từ cán bộ chuyên trách… Tác nhân: văn thư Tiền điều kiện: người dùng đăng nhập vào Portal với đặc quyền của văn thư Dòng chính: Bước 1: mở hòm thư cá nhân Bước 2: duyệt nội dung các thông báo Người có thẩm quyền duyệt nội dung công văn use case này áp dụng cho cán bộ có đặc quyền giải quyết các công văn đến thuộc về trách nhiệm của mình Tác nhân: cán bộ chuyên trách, trưởng các bộ phận, giám đốc Tiền điều kiện: người dùng phải đăng nhập thành công vào Portal và có quyền truy nhập đến phần công văn đến Dòng chính: Người dùng mở phần công văn đến Duyệt nội dung công văn đến, có thể là theo ngày, theo vần, theo mã code… Trưởng bộ phận chỉ định cán bộ chuyên trách dự thảo công văn: use case này áp dụng cho trưởng bộ phận chỉ định cán bộ chuyên trách dự thảo một bản công văn để gửi đi Tác nhân: trưởng các bộ phận Tiền điều kiện: đăng nhập thành công vào Portal với đặc quyền của trưởng bộ phận Dòng chính: Người dùng di chuyển đến phần gửi công văn đi Lựa chọn một trong số những cán bộ chuyên trách để giao cho họ nhiệm vụ dự thảo một bản công văn để chuyển đi, nội dung công văn có thể là thư mời, quyết định, chỉ thị, thông báo… Gửi thông báo cho cán bộ chuyên trách Nhận bản dự thảo từ cán bộ chuyên trách Use case này áp dụng cho trưởng các bộ phận để nhận bản dự thảo công văn từ cán bộ chuyên trách được giao nhiệm vụ Tác nhân: trưởng các bộ phận Tiền điều kiện: người dùng phải đăng nhập thành công vào Portal với đặc quyền của trưởng các bộ phận. Dòng chính: Người dùng di chuyển đến phần nhận bản thảo trong phần công văn đi Lựa chọn một hoặc nhiều dòng để lấy bản thảo Nhấn nút lưu để nhận các bản thảo Trình tổng giám đốc ký duyệt Use case này để các trưởng bộ phận trình lên tổng giám đốc các bản dự thảo công văn để gửi đi Tác nhân: trưởng các bộ phận Tiền điều kiện: phải đăng nhập thành công vào Portal với đặc quyền của trưởng bộ phận Dòng chính: Người dùng di chuyển đến phần trình bản dự thảo lên tổng giám đốc phê duyệt Chọn một hoặc nhiều file cần gửi đi Thêm vào các chú thích nếu cần thiết Gửi các file lên tổng giám đốc Dòng thay thế: Người dùng chọn nhầm file: Cho phép chọn lại Hậu điều kiện: các bản thảo phải đến được tổng giám đốc Thông báo cho văn thư có công văn cần gửi đi Use case này để trưởng các bộ phận thông báo cho văn thư biết có công văn cần được gửi đi Tác nhân: trưởng các bộ phận Tiền điều kiện: sau khi bản thảo đã được tổng giám đốc phê duyệt và người dùng phải đăng nhập thành công vào Portal. Dòng chính: Người dùng di chuyển đến phần gửi thông báo Chọn người gửi thông báo là văn thư Ghi nội dung thông báo Gửi thông báo đến văn thư Yêu cầu bản mềm từ cán bộ được ủy quyền Use case này áp dụng khi văn thư yêu cầu cán bộ chuyên trách chuyển đến một bản mềm công văn cần gửi đi Tác nhân: văn thư Tiền điều kiện: văn thư đã đăng nhập thành công vào hệ thống Dòng chính: Văn thư di chuyển đến phần xử lý công văn đi Chọn một người trong danh sách cán bộ được ủy quyền dự thảo công văn đi Ghi thông báo Gửi đi Nhận bản mềm từ cán bộ ủy quyền Use này áp dụng khi văn thư nhận một bản mềm của công văn cần gửi đi từ cán bộ chuyên trách Tác nhân: văn thư Tiền điều kiện: người dùng đăng nhập thành công vào hệ thống Dòng chính: Người dùng di chuyển đến phần gửi công văn đi Duyệt nội dung các thông báo gửi đến Nhấn nút để lưu file lên đĩa Ghi số công văn đi vào Portal Use case này áp dụng khi văn thư lưu công văn đi vào portal Tac nhân: văn thư Tiền điều kiện: người dùng phải đăng nhập thành công vào hệ thống Tiền điều kiện: đã nhận được bản mềm từ cán bộ chuyên trách Dòng chính: Văn thư di chuyển đến phần gửi công văn đi Vào phần lưu trữ công văn Thêm một dòng mới vào phần lưu trữ Điền các thông tin vào dòng mới bao gồm: mã công văn gửi đi, ngày tháng, nội dung cơ bản … Lưu lại bản mềm của công văn gửi đi Dòng thay thế: Khi nhập mã công văn trùng với một mã đã có trước đó: Cho phép xóa dòng công văn hoặc cho phép nhập lại Hậu điều kiện: các thông tin cần thiết phải được cập nhật vào trong CSDL Tạo thư mục Use case này sử dụng để tạo ra các thư mục ảnh để tham gia bình chọn ảnh Tác nhân: quản trị web, quản trị nội dung Tiền điều kiện: người dùng đăng nhập vào Portal với đặc quyền của người quản trị Portal hoặc là người quản trị nội dung Dòng chính: Người dùng vào phần bình chọn ảnh Tạo ra một thư mục mới để tham gia bình chọn ảnh Chọn thư mục Dùng để lựa chọn thư mục ảnh trong hệ thống để xem hoặc bình chọn Tác nhân: quản trị Portal hoặc quản trị nội dung Chỉnh sửa ảnh Use case này dùng để chỉnh sửa ảnh và chỉnh thuộc tính của ảnh Tác nhân: quản trị portal, quản trị nội dung Tiền điều kiện: đăng nhập vào hệ thống với vai trò của quản trị Portal hoặc quản trị nội dung Dòng chính: Người dùng vào mục chỉnh sửa ảnh Chọn một ảnh Thay đổi các thông số ảnh như: tên ảnh, chiều cao, mô tả, ngày chỉnh sửa … Hậu điều kiện: các thay đổi phải được cập nhật trong CSDL Tải ảnh: Dùng để tải ảnh lên hệ thống Tác nhân: quản trị Portal hoặc quản trị nội dung Tiền điều kiện: đăng nhập thành công vào hệ thống Dòng chính: Vào mục tải ảnh Chọn một hoặc nhiều ảnh Tải ảnh lên hệ thống Hiển thị ảnh: Dùng để hiển thị ảnh của hệ thống Tác nhân: người dùng hệ thống Bình chọn ảnh: Dùng để bình chọn các ảnh theo một sự kiện nào đó mà người quản trị đưa ra Tác nhân: người dùng hệ thống Đặt cơm trưa U-Case này để đăng ký cơm trưa Tác nhân: người dùng hệ thống Tiền điều kiện: Người dùng đã đăng nhập vào hệ thống Hậu điều kiện: Sự đăng ký của người dùng phải được cập nhật Dòng chính: Người dùng vào phần đang ký cơm trưa Điền các thông tin vào Web Part (bao gồm giá tiền) Nếu sự thay đổi diễn ra trước 11h thì cập nhật vào cơ sở dữ liệu Dòng thay thay thế: Nếu đăng ký diễn ra sau 11h thì đưa ra thông báo đã hết hạn đang ký cơm Thiết kế hệ thống Hệ thống được xây dựng dựa trên mô hình đối tượng của WSS, ta sẽ sử dụng lại các lớp mà WSS cung cấp, bên cạnh đó cũng có một tập hợp rộng lớn các Web Services mà WSS đưa ra, ta có thể dễ dàng sử dụng chúng khi cần thiết. Một số đối tượng của WSS nằm trong gói Microsoft. Cũng trong phần này, do một số biểu đồ trình tự có nội dung gần giống nhau nên tác giả chỉ đưa ra một số biểu đồ chính, còn những biểu đồ còn lại có thể suy ra từ những biểu đồ này. Biểu đồ lớp của hệ thống Biểu đồ trình tự cho hiển thị kết quả tìm kiếm Biểu đồ trình tự cho Use case đăng nhập Biểu đồ trình tự cho Use case nhập mã công văn đến vào Portal Biểu đồ trình tự cho Use case chúc mừng sinh nhật Biểu đồ trình tự đặt cơm trưa Biểu đồ trình tự chấm công Triển khai Yêu cầu về phần mềm Hệ điều hành Windows Server 2003 Sp1 IIS 6.0 và ASP.NET Windows SharePoint Services SharePoint Portal Server MS Sql Server 2000 Sp4 Yêu cầu về phần cứng Tối thiểu 1GB bộ nhớ RAM Tối thiểu 80GB dung lượng ổ cứng Vi xử lý Intel Pentium4, tối thiểu 2.26 GHz Triển khai trên máy chủ đơn Ứng dụng chạy trên máy chủ đơn , máy chủ này sẽ chạy cả máy chủ Web và máy chủ CSDL với 2 CSDL là CSDL nội dung và CSDL cấu hình. Số lượng người dùng bé hơn 1000 người. Kết luận và hướng phát triển Kết luận Ưu điểm Hiện nay có rất nhiều công nghệ để xây dựng nên các cổng thông tin điện tử, mỗi công nghệ có một điểm mạnh riêng vì vậy tùy vào từng ứng dụng cụ thể, từng hoàn cảnh cụ thể mà nên lựa chọn một công nghệ nào cho phù hợp. Các công nghệ dựa trên Java như JSR-168, WSRP có lợi thế là có thể chạy trên nhiều hệ điều hành khác nhau chẳng hạn Windows, Linux … tuy nhiên nó không được sự hỗ trợ nhiều từ Microsoft, mặt khác các công cụ trợ giúp thiết kế còn hạn chế; còn sản phẩm SharePoint của Microsoft có thể xem như là “con đẻ” của Microsoft nên nó nhận được sự hỗ trợ rất mạnh mẽ từ Microsoft, đặc biệt nó được thừa hưởng nhiều dịch vụ và kiến trúc từ bản thân hệ điều hành Windows (chẳng hạn dịch vụ tìm kiếm đánh chỉ mục, các dịch vụ về bảo mật …) và sự hỗ trợ từ các sản phẩm phần mềm khác của Microsoft (chẳng hạn Microsoft Office), các công cụ trợ giúp thiết kế của nó cũng tương đối nhiều (chẳng hạn Front Page hay môi trường phát triển trong Visual Studio .NET), nó cũng tích hợp chặt chẽ với Visual Studio .NET trong việc phát triển ứng dụng. Ngoài ra còn có một số sản phẩm làm Portal dựa trên nền .NET như RainBow, DotNetNuke nhưng chúng vẫn bộc lộ khá nhiều hạn chế. RainBow là một sản phẩm nguồn mở nhưng cộng đồng phát triển nó còn rất nhỏ bé, mặt khác tuy nói nó là nguồn mở nhưng khi cần mở rộng thì ta cũng phải mua khá nhiều Plugin từ những nơi khác; còn DotNetNuke là một sản phẩm nguồn mở rất có giá trị, cộng đồng phát triển nó cũng tương đối lớn nhưng theo đánh giá của nhiều người thì tốc độ thực thi của nó vẫn còn chậm và nặng nề, nó vẫn nhận được sự hỗ trợ từ Microsoft tuy nhiên sự hỗ trợ đó không được nhiều. SharePoint đặc biệt thích hợp trong bài toán “cổng thông tin nội bộ cho các doanh nghiệp” bởi vì: Hiện nay các cổng thông tin về thương mại điện tử, các cổng thông tin công cộng rất nhiều nhưng cái “sát sườn” nhất đối với mỗi tổ chức đó là cổng nội bộ cho chính tổ chức đó lại chưa có dẫn đến việc trao đổi, chia sẻ và hợp tác về thông tin trong nội bộ tổ chức vẫn còn rất nhiều hạn chế, thiếu nhất quán và chưa thông suốt. Đối với mỗi tổ chức, mỗi doanh nghiệp thì vấn đề trao đổi, chia sẻ, hợp tác về mặt thông tin giữa các thành viên là rất cần thiết để nâng cao năng suất cũng như chất lượng trong công việc. Sản phẩm SharePoint của Microsoft nhằm hướng đến một cổng thông tin với khả năng hợp tác, chia sẻ thông tin rất mạnh mẽ, do vậy có thể xem nó là một trong những ưu tiên hàng đầu cho vấn đề này. Với mỗi người dùng trong công ty thì yêu cầu về tùy biến và cá nhân hóa là rất lớn, mỗi người không ai giống ai đều muốn cách tiếp nhận các nguồn thông tin theo sở thích của mình, đó cũng là một yếu tố để nâng cao chất lượng công việc. SharePoint được xây dựng để hướng đến một cổng thông tin với các dịch vụ về tùy biến và cá nhân hóa rất cao với sự hỗ trợ của công nghệ Web Part Đối với mỗi người dùng thì vấn đề tìm kiếm thông tin một cách nhanh chóng là một nhu cầu rất lớn, đó cũng là một yếu tố làm nâng cao năng suất và chất lượng công việc. SharePoint hỗ trợ dịch vụ tìm kiếm nhanh bằng phương pháp đánh chỉ mục. Hỗ trợ dịch vụ đăng nhập một lần (Single Sign on), hệ thống sẽ tự động nhận ra mỗi người dùng và cho phép họ sử dụng những dịch vụ được tích hợp trong Portal mà không phải đăng nhập hay xác nhận lại nhiều lần SharePoint cũng hỗ trợ một số dịch vụ rất cần cho các doanh nghiệp như nhóm thảo luận, hội thảo… Một trong những ưu điểm nữa của SharePoint đó là khả năng tích hợp với các ứng dụng lớn, chẳng hạn như: BizTalk, K2.NET, InforPath … từ đó có thể xây dựng các ứng dụng về thương mại điện tử với quy mô lớn. Nhược điểm Sau đây là một số nhược điểm chính của SharePoint Nhược điểm lớn nhất của SharePoint đó là nó chỉ chạy được trên nền của hệ điều hành Windows Server 2003; có thể nói các thành phần: Windows Server 2003, SharePoint, Microsoft Office và Sql Server đi kèm với nhau thì tạo thành một cỗ máy cực kì mạnh mẽ nhưng rất nặng nề và cồng kềnh, không phải lúc nào cũng dễ dàng triển khai. Là một sản phẩm “nguồn đóng”, giá bản quyền của SharePoint không nhỏ Hiện tại Microsoft không hỗ trợ SharePoint chạy trên các trình duyệt khác như FireFox, Mozilla, … đây cũng là ý đồ của Microsoft muốn chiếm vị trí độc tôn Các thành phần, các dịch vụ gắn chặt với các sản phẩm của Microsof do vậy việc phát triển SharePoint trên các nền khác như Linux là điều không thể Mặc dù đã tích hợp với môi trường phát triển của VS.NET, tuy nhiên việc viết các Web Part không hề đơn giản Đánh giá về đồ án Những việc đã làm được Đã tìm hiểu khá chi tiết về lý thyết, về công nghệ xây dựng cổng thông tin điện tử Đã làm chủ được hầu hết mọi khía cạnh của công nghệ SharePoint Hoàn thành phần ứng dụng “Cổng thông tin quản lý nội bộ doanh nghiệp”. Tuy nhiên phần giao diện chưa thật sự thân thiện và dễ dùng. Nắm được một số công nghệ về Web hiện nay như: ASP.NET, Web Services… Những khó khăn và hạn chế Do đặc thù của bài toán là “cổng thông tin nội bộ cho công ty” nên nó hướng đến các nhu cầu thiết thực của mỗi nhân viên trong công ty như chia sẻ tài liệu, nhận biết các thay đổi và cảnh báo, khả năng cộng tác… vì thế chưa có điều kiện để tích hợp SharePoint với các ứng dụng thương mại điện tử lớn như BizTalk cũng như phát triển một cổng thông tin quy mô Internet. Các tài liệu về SharePoint rất nhiều nhưng thường nằm phân tán trên Internet, còn nếu có sách viết về SharePoint một cách đầy đủ thì giá của nó cũng khá đắt. Trong quá trình làm đồ án do tác giả trước đây chỉ quen với lập trình Win Form, lập trình C/C++ trên môi trường Linux … cho nên khi chuyển sang lập trình Web cảm thấy hơi bỡ ngỡ, có nhiều khái niệm phải tìm hiểu từ đâu; tuy nhiên được sự hướng dẫn tận tình của Thầy giáo cũng như các anh chị CNPM khóa trước, tác giả đã nhanh chóng tiếp thu và làm chủ được công nghệ. Hướng phát triển Như trên đã đề cập, nhược điểm rất lớn của SharePoint đó là gắn chặt với nền Windows Server 2003 và các sản phẩm khác của Microsoft, nó không thể triển khai trên các hệ điều hành khác (chẳng hạn Linux); tuy nhiên các ý tưởng và kiến trúc trong công nghệ SharePoint là cực kỳ thông minh. Do vậy, hướng phát triển tiếp theo của em trong tương lai là xây dựng một FrameWork lấy các ý tưởng từ SharePoint, tuy nhiên FrameWork này phải linh động, dễ dàng triển khai trên các hệ điều hành khác nhau (chẳng hạn trên Windows lẫn Linux). Ở đây em xin được trình bày tóm lược các đặc điểm của FrameWork này như sau: Đưa vào 3 khái niệm mới: Container: Là một đơn vị của trang Web, nó là một thành phần giao diện để hiển thị thông tin và dữ liệu, nó cũng là một thùng chứa nội dung. Container Environment: Là môi trường thực thi cho các Container, nó có trách nhiệm tạo lập và hủy các Container trong nó khi cần thiết. Container Zone: Dùng để định vị các Container cũng như cấu trúc, bố cụ c của trang Web. Mỗi trang Web được cấu thành từ các Container Zone, mỗi Container Zone sẽ có một ZoneID ứng với nó, các Container Zone sẽ tạo nên khung của một trang Web và khung này có thể tạo ra bằng cách: Hoặc đọc nội dung từ CSDL MySQL thay vì SQL Server 2000 Hoặc đọc nội dung từ một file XML Khi một trang Web được tải vào thì nó sẽ tải lần lượt các ContainerZone với ID đã được định rõ trong CSDL. CSDL ứng dụng bao gồm 2 phần: CSDL nội dung: lưu trữ các thông tin về mặt nội dung của hệ thống CSDL cấu hình: dùng để cấu hình hệ thống Dữ liệu của một trang Web có thể lưu trong CSDL MySQL hoặc lưu trong các List, các List là một biến thể của các các bảng CSDL, nó có thể lưu trữ nhiều loại thông tin (chẳng hạn lưu trữ File). Các dịch vụ (chẳng hạn tùy biến) chạy ở dạng Web Service Sử dụng các ngôn ngữ không phụ thuộc nền như: PHP, Java, Perl Một số hướng phát triển khác nữa trong tương lai: Xây dựng một Tool cho phép tạo ra các Web Parts theo dạng kéo thả, hiện tại việc viết các Web Part rất vất vả vì người lập trình phải Render ra các đoạn mã (chẳng hạn HTML) từ chế độ soạn thảo. Viết các ứng dụng thương mại điện tử Internet với SharePoint trong đó có tích hợp với các sản phẩm về TMDT như BizTalk Tài liệu tham khảo Administrator's Help.chm User's Help.chm HowSharePointWork.pdf SharePointGuide.doc WorkingWithWebPartPage.doc ConnectingWebPart.doc OverviewOfWebPartsFramework.doc SharePointPortalServer2003POCGuide.pdf SharePointTips.doc MicrosoftWebEnterprisePortal.doc Microsoft SharePoint Products and Technologies 2003 Software Development Kit Introducing Windows SharePoint Services HowSharePointWork.pdf (trang 2, 7, 10, 11, 13, 15, 18) SharePointGuide.doc (trang 5, 8,12,16)