Xử lý lỗi trong IBM Worklight adapters

Xử lý lỗi trong IBM Worklight adapters Khi các công ty mở rộng dịch vụ của họ lên các thiết bị di động thì những lo ngại về bảo mật dữ liệu, tính linh động và minh bạch dữ liệu cần phải được giải quyết. Framework ứng dụng di động cho IBM® Worklight® có thể giải quyết những lo ngại này thông qua một cơ chế chuyển đổi gọi là adapter. Worklight adapters là những thành phần được triển khai đến máy chủ trên nền tảng di động Worklight để truy cập vào các dịch vụ doanh nghiệp. Chúng đóng vai trò là cầu nối giữa các ứng dụng di động và hệ thống doanh nghiệp, nhận những yêu cầu từ thiết bị di động và trả về thông tin lấy được từ hệ thống. Khi thiết kế các adapter, việc xử lý lỗi là rất quan trọng, cần được suy nghĩ cẩn thận với mục tiêu là cung cấp thông tin lỗi cho các ứng dụng di động một cách rõ ràng và hợp lý để giảm thiểu tính phức tạp của ứng dụng di động. Bài viết này cung cấp cho bạn một số lời khuyên trong việc xử lý lỗi adapter, xuất phát từ những kinh nghiệm thực tế qua quá trình phát triển ứng dụng và adapter trên Worklight Với vai trò là cầu nối giữa ứng dụng di động và hệ thống doanh nghiệp, IBM Worklight adapters cung cấp khả năng truy cập bảo mật đến hệ thống và nâng cao tính minh bạch bằng cách trình bày dữ liệu doanh nghiệp trên thiết bị di động theo một định dạng thống nhất. Worklight cung cấp 3 loại adapter:  HTTP adapters cung cấp khả năng truy cập các dịch vụ doanh nghiệp dựa trên HTTP, bao gồm các dịch vụ RESTfull và SOAP.  SQL adapters cung cấp khả năng truy cập vào cơ sở dữ liệu doanh nghiệp.  Cast Iron® adapters bắt đầu được thêm vào IBM WebSphere Cast Iron. Được viết bằng JavaScript™, adapters chạy trên nền tảng di động Worklight ở phía server, nó sử dụng công cụ Rhino JavaScript để thực thi mã nguồn JavaScript. Hình 1 mô tả cái nhìn đơn giản về adapter framework bên trong nền tảng Worklight lớn hơn. Hình 1. Mô tả adapter framework Theo định nghĩa, adapter là một tập hợp các tính năng JavaScript có thể được gọi từ xa bởi một ứng dụng. Từ quan điểm lập trình, một adapter bao gồm:  Một file XML để cấu hình kết nối từ adapter đến hệ thống doanh nghiệp và liệt kê các thủ tục adapter để các ứng dụng di động có thể gọi tới được.  Một file JavaScript chứa các đoạn mã thực thi của các thủ tục (chức năng) adapter được viết bằng JavaScript. Hai file này được chứa trong gói file .adapter và sau đó được triển khai trên IBM Worklight Server. Sau khi được triển khai, các thủ tục adapter đã sẵn sàng được gọi bởi các ứng dụng Worklight trên các thiết bị di động hay trên trình duyệt. Xem mục Tài nguyên để tìm hiểu thêm về adapters. Xử lý lỗi adapter Các thủ tục trong adapter chính là các hàm JavaScript có thể lấy bất kỳ thông số giá trị nào và trả về một đối tượng JavaScript cho các ứng dụng client đang gọi tới. Ví dụ trong bài này, chúng ta sử dụng một ứng dụng di động của ngân hàng và một thủ tục adapter được gọi là transfer, mục đích là sử dụng dịch vụ RESTful trong hệ thống để tiến hành chuyển tiền giữa các tài khoản ngân hàng. Như trong Liệt kê 1, thủ tục chuyển tiền có thể nhận vào ba thông số, sử dụng hàm WL.Server.invokeHttp trong bộ thư viện Worklight API để gọi tới dịch vụ chuyển tiền trong hệ thống, sau đó sẽ trả về cho người dùng thông tin phải hồi từ hệ thống. Hàm WL.Server.invokeHttp thuộc bộ thư việc Worklight API chạy ở phía server và được dùng để gọi tới một dịch vụ RESTful (HTTP). Còn đối với việc tương tác vào cơ sở dữ liệu, SQL adapters có thể gọi các hàm API WL.Server.invokeSQLStatement và WL.Server.invokeSQLStoredProcedure. Liệt kê 1. Thủ tục chuyển tiền thông qua adapter 1 // Adapter procedure to invoke the bank’s transfer service 2 // via HTTP 3 function transfer (fromAccount, toAccount, amount) { 4 5 // Build the WL.Server.invokeHttp input object to invoke the 6 // transfer service 7 var service = "transferservice?fromAccount=" +fromAccount+ 8 "&toAccount=" +toAccount+ "&amount=" +amount; 9 var input = { 10 method : 'get', 11 returnedContentType : 'json', 12 path : service 13 }; 14 15 // Invoke the enterprise service to the transfer funds 16 var response = WL.Server.invokeHttp(input); 17 18 // Return the response received from the transfer service to 19 // the caller 20 return response; 21 } Luồng gọi adapter Để hình dung căn bản về việc xử lý lỗi mà chúng ta đang thảo luận, hãy cùng xem qua luồng hoạt động của một ứng-dụng-gọi-tới-adapter điển hình: 1. Khi bắt đầu, ứng dụng Worklight sẽ gọi tới thủ tục adapter bằng cách dùng hàm WL.Client.invokeProcedure ở phía client, hàm này có trong bộ thư viện Worklight client-side API. Người dùng sẽ cung cấp các thông tin về adapter muốn gọi – tên adapter, thủ tục, các thông số đầu vào – và cả các thông tin tùy chọn như thông tin phản hồi nếu thực hiện thành công hay thất bại, bạn có thể xem minh họa ở Liệt kê 2. Liệt kê 2. Ứng dụng client gọi tới thủ tục "transfer" (chuyển tiền) của adapter 1 WL.Client.invokeProcedure( 2 // Invocation data 3 { 4 adapter : "BankServiceAdapter", 5 procedure : "transfer", 6 parameters : [fromAccount, toAccount, amount] 7 }, 8 // Options object 9 { 10 // Success handler function 11 onSuccess : function(resp) { 12 var confirmationCode = 13 resp.invocationResult.transferResult.confirmationCode; 14 WL.Logger.debug("Transfer succeeded, conf code = " 15 + confirmationCode); 16 }, 17 // Failure handler function 18 onFailure : function(resp) { 19 WL.Logger.debug("Transfer failed, errors = " 20 + resp.invocationResult.errors.join(",") ); 21 } 22 } 23 ); 2. Thủ tục chuyển tiền của adapter này sau đó được gọi trên Worklight Server và sẽ thực hiện một hoạt động trong hệ thống, như là gọi dịch vụ RESTful để thực hiện chuyển tiền trong hệ thống (đã được mô tả trong Liệt kê 1). 3. Khi thủ tục hoàn thành, nó trả về một đối tượng phản hồi. 4. Tùy vào tình trạng của việc gọi thủ tục mà đối tượng phản hồi sẽ nhận được thông điệp thành công hay thất bại. Bây giờ chúng ta hãy xem xét kỹ hơn về đối tượng phản hồi và điều kiện nào để quyết định thông điệp thành công hay thất bại. Xử lý thành công đối tượng phản hồi Đối tượng phản hồi được xử lý thành công có thể chứa các thuộc tính như trong Bảng 1 (và các thuộc tính có thể được thêm vào). Bảng 1. Xử lý đối tượng phản hồi Thuộc tính Mô tả invocationContextĐối tượng invocationContext nếu được thông qua từ thiết bị di động của khách hàng trong một đối tượng tùy chọn WL.Client.invokeProcedure. status Tình trạng phản hồi HTTP (chỉ dành cho các HTTP adapters). invocationResult Là một đối tượng chứa dữ liệu được trả về từ các thủ tục adapter được gọi và tình trạng của việc gọi. Nó được định dạng như sau: invocationResult = { isSuccessful: Boolean, errors : ["error Thuộc tính Mô tả message", “error message” …], warnings : ["warning message", “warning message” …], info : ["info message", “info message” …], // Procedure results go here } Ở đó:  isSuccessful – được thiết lập là true nếu kết nối được thiết lập từ đầu tới cuối giai đoạn xử lý, ngược lại là false  errors – một mảng string chứa các thông điệp lỗi  warnings – một mảng string chứa các thông điệp cảnh báo  info – một mảng string chứa các thông tin Ví dụ, việc xử lý thành công cho lời gọi thủ tục transfer adapter có thể nhận một đối tượng phản hồi với thuộc tính invocationResult (xem Liệt kê 3). Liệt kê 3. Ví dụ invocationResult xuất ra xử lý thành công invocationResult : { isSuccessful: true, errors : [], warnings : [], info : [], statusCode: 200, statusReason: "OK", transferResult : { confirmationCode : "446183348", amount : "$2000.00" } } Trong ví dụ trên, 6 thuộc tính đầu tiên được tự động thêm vào bởi Worklight và thuộc tính transferResult là một phần của kết quả thủ tục bao gồm các đối tượng phản hồi bởi thủ tục adapter. Xử lý thất bại đối tượng phản hồi Xử lý thất bại được gọi khi có lỗi ở cả phía server và client xảy ra trong suốt quá trình gọi thủ tục adapter. Những lỗi này có thể bắt nguồn từ 2 trường hợp: một lỗi kỹ thuật - technical failure, chẳng hạn như kết nối thất bại hay hết thời gian chờ trong quá trình gọi khiến cho không gọi được thủ tục, và lỗi ở tầng ứng dụng - application level failure trong trường hợp thủ tục được gọi nhưng thất bại. Khi xảy ra lỗi kỹ thuật, đối tượng phản hồi thông qua bộ xử lý lỗi sẽ chứa các thuộc tính như ở Bảng 2. Bảng 2. Các thuộc tính trong đối tượng phản hồi thất bại Thuộc tính Mô tả invocationContextĐối tượng invocationContext nếu được thông qua từ thiết bị di động của khách hàng trong một đối tượng tùy chọn WL.Client.invokeProcedure. status Tình trạng phản hồi HTTP (chỉ dành cho các HTTP adapters). errorCode Một mã lỗi kiểu string Thuộc tính Mô tả errorMsg Một thông điệp lỗi từ IBM Worklight Server. Ví dụ, khi kết nối đến Worklight Server bị gián đoạn trước khi thủ tục SQL adapter được gọi thì đối tượng phản hồi sẽ nhận một xử lý thất bại chứa ba thuộc tính sau: invocationContext : "" errorCode : "UNRESPONSIVE_HOST" errorMsg : "The service is currently not available. " Đối với nguyên nhân thứ hai dẫn đến việc gọi thất bại — thủ tục được gọi như thất bại — thì việc xử lý thất bại cũng được thông qua giống như phản hồi ở Bảng 1, nhưng lúc này thuộc tínhisSuccessful sẽ được thiết lập là false. Ví dụ, khi thủ tục HTTP adapter ở Liệt kê 1 được gọi trong khi hệ thống máy chủ xử lý bị mất kết nối, thì đối tượng phản hồi sẽ nhận một xử lý thất bại chứa các thuộc tính như Liệt kê 4. Liệt kê 4. Ví dụ về invocationResult xuất ra xử lý thất bại invocationResult { errors: [ "Runtime: Http request failed: org.apache.http.conn.HttpHostConnectException: Connection to refused" ], warnings: [], info: [], isSuccessful: false } Một trường hợp khác dẫn đến xử lý thất bại là những dữ liệu phản hồi được trả về từ dịch vụ hệ thống không thể được chuyển đổi trực tiếp bởi đầu vào returnedContentType thông qua WL.Server.invokeHttp. Trường hợp mở rộng xử lý lỗi trong các thủ tục adapter Trong phần thảo luận vừa rồi về việc xử lý lỗi, chúng ta đã tập trung vào những trường hợp mà nền tảng Worklight phát hiệu ra lỗi và từ đó gọi xử lý thất bại. Mặc định, Worklight adapters khác với (hay không biết đến) các lỗi ở tầng ứng dụng. Ví dụ, nếu một thủ tục HTTP adapter gọi một dịch vụ hệ thống mà sau đó nó phản hồi về một lỗi HTTP 500 Internal Server Error, thì nền tảng Worklight sẽ gọi đến xử lý thành công ở phía client — không phải xử lý thất bại — và qua đó, các đối tượng phản hồi sẽ có các thuộc tính như Liệt kê 5. Liệt kê 5. InvocationResult thông qua xử lý thành công với lỗi HTTP 500 Internal Server Error invocationResult { isSuccessful : true, errors : [], warnings : [], info : [] statusCode : 500, statusReason : "Internal Server Error" } Điều này tạo ra gánh nặng cho các nhà phát triển ứng dụng client rằng đòi hỏi họ phải hiểu sâu về mối tương tác giữa adapter với hệ thống doanh nghiệp để có thể phát hiện các trường hợp lỗi có thể xảy ra. Trong khi các nhà phát triển yêu thích việc lập trình theo hướng dễ dàng – kịch bản đó luôn luôn thành công – thì trong thực tế, việc viết mã để xử lý lỗi là việc cần thiết, thậm chí nó còn tốn gấp đôi hay gấp ba công sức lập trình. Do đó, bất kỳ kỹ thuật xử lý lỗi nào giúp đơn giản hóa ứng dụng client thì đều có khả năng giúp cho mã code rõ ràng hơn và sẽ tạo ra một ứng dụng mạnh mẽ hơn. Dựa vào những kinh nghiệm trong việc phát triển ứng dụng client và adapter trên Worklight, tôi và một đồng nghiệp đã tìm cách cải thiện việc xử lý lỗi adapter trong các dự án Worklight tiếp theo. Sau khi xem xét, chúng tôi đưa ra hai hướng dẫn sau: 1. Các thủ tục adapter nên sử dụng một cơ chế báo lỗi phù hợp để gọi tới client do đó client không cần phải có kiến thức về các dịch vụ adapter-đến-hệ- thống-doanh-nghiệp. 2. Cơ chế này phải phù hợp với mô hình xử lý phản hồi của Worklight hiện tại. Những hướng dẫn này dễ dàng được đáp ứng nhờ vào sự linh hoạt của cơ chế xử lý phản hồi của Worklight adapter. Cụ thể, bằng cách tận dụng những thuộc tính lỗi hiện tại có trong tất cả phản hồi adapter để cung cấp lỗi cho tầng ứng dụng, các ứng dụng client chỉ cần xem thông tin lỗi ở một nơi và không cần phải hiểu cụ thể về adapter và dịch vụ doanh nghiệp. Ví dụ, Liệt kê 6 cập nhật các thủ tục transfer adapter được thể hiện ở trên và thêm vào đoạn mã để kiểm tra lỗi ở tầng ứng dụng (dòng 15-33) và sau đó cung cấp thông tin lỗi cho ứng dụng client thông qua thuộc tính phản hồi lỗi. Liệt kê 6. Thủ tục transfer adapter procedure cập nhật xử lý lỗi ở tầng ứng dụng 1 function transfer (fromAccount, toAccount, amount) { 2 3 // Build the WL.Server.invokeHttp input object 4 var service = "transferservice?fromAccount=" +fromAccount+ 5 "&toAccount=" + toAccount+ "&amount=" +amount; 6 var input = { 7 method : 'get', 8 returnedContentType : 'json', 9 path : service 10 }; 11 12 // Invoke the enterprise service to the transfer funds 13 var response = WL.Server.invokeHttp(input); 14 15 // Check for application level errors 16 if (response.statusCode == 200) { 17 // Did we receive a transfer confirmation code? 18 if (response.transferResult.confirmationCode != "") { 19 WL.Logger.debug("Successful transfer, conf code = " 20 + response.transferResult.confirmationCode); 21 } else { 22 // Tell client that transfer failed 23 response.errors.push("Transfer failed, errNo = " 24 + response.transferResult.errNo); 25 WL.Logger.debug(response.errors); 26 } 27 } else { 28 // Tell client that transfer failed with non-success 29 // HTTP status 30 response.errors.push("Transfer failed, HTTP status =" 31 + response.statusCode); 32 WL.Logger.debug(response.errors); 33 } 34 35 // Return response received from transfer service to caller 36 return response; 37 } Cung cấp cho adapter khả năng xử lý lỗi ở mức ứng dụng và truyền thông tin lỗi về lại phía ứng dụng client cho phép dễ dàng đáp ứng các hướng dẫn của chúng tôi, và tạo cơ sở khuyến cáo sử dụng kỹ thuật xử lý lỗi tốt nhất ở phần tiếp theo. Những khuyến nghị xử lý lỗi adapter 1. Ứng dụng lá chắn cụ thể từ adapter-đến-hệ-thống-doanh-nghiệp Đừng lẫn lộn Trong khi việc thiết lập thuộc tính isSuccessful trong thủ tục adapter là một việc thú vị — giá trị của nó kiểm soát cho dù ứng dụng gọi thành công hay không — thì hành vi kết quả là không có cơ sở và có thể thay đổi trong tương lai. Do đó, giá trị của isSuccessful thiết lập bởi các lời gọi Worklight API thì tốt nhất là nên giữ nguyên. Như đã thảo luận ở trên, nền tảng Worklight không xem lỗi ở mức ứng dụng là một thất bại. Ví dụ, khi một adapter gọi một yêu cầu dịch vụ HTTP, một phản hồi Từ chối kết nối - Connection Refused được coi là một thất bại và được chỉ định để xử lý thất bại, nhưng một phản hồi HTTP với tình trạng 500 Internal Server Error từ các dịch vụ doanh nghiệp thì không được xem là lỗi mà lại được chỉ định đến xử lý thành công. Tình huống thất bại này nên được xử lý bởi adapter theo cách mà các ứng dụng client miễn phí cần biết để tương tác với adapter và dịch vụ doanh nghiệp. Cách tiếp cận này được chỉ ra trong Liệt kê 7, trong đó thủ tục adapter gọi một dịch vụ trả về một tập hợp các mã phản hồi cụ thể, thất bại. Bắt giữ các loại thất bại này trong thủ tục adapter thay vì các ứng dụng client bảo vệ các ứng dụng từ dịch vụ doanh nghiệp, bị lỗi cụ thể. Listing 7. Failure handling when the enterprise service indicates an error 1 // Issue the Transfer Funds HTTP request 2 var response = WL.Server.invokeHttp(input); 3 4 // Any problems? 5 if (response.transferResult.errNo != 0) { 6 if (response.transferResult.errNo == 1) { 7 response.transferResult.errors.push( 8 "Transfer service is down for maintenance"); 9 } else if (response.transferResult.errNo == 2) { 10 response.errors.push( 11 "Transfer not permitted between these accounts"); 12 } else { 13 response.errors.push( 14 "Transfer service failed with unknown errNo: " 15 + response.transferResult.errNo); 16 } 17 WL.Logger.debug(response.errors); 18 } 2. Báo cáo thông tin lỗi cho client theo cách nhất quán Việc trả về các dấu hiệu để thông báo lời gọi thất bại là một việc cần thiết. Ngoài ra, bạn nên thường xuyên cung cấp dấu hiệu này ở vị trí phù hợp, chẳng hạn trong một thuộc tính phản hồi cụ thể. Một thuộc tính logic cho thông tin lỗi này là mảng errors được cung cấp trong đối tượng phản hồi của nền tảng Worklight. Điều này được sử dụng trong đoạn mã adapter ở Liệt kê 7 (dòng 7, 10 and 13). Thuộc tính bổ lỗi liên quan có thể được thêm vào phản hồi nếu muốn, chẳng hạn như một thuộc tính mã lỗi. 3. Các thủ tục Code adapter dự phòng Cách lập trình tốt nhất là bắt lỗi từ phía client khi tiến hành gọi các thủ tục adapter, như trong Liệt kê 8 (dòng 4 - 17). Liệt kê 8. Phát hiện các thông số đầu vào sai 1 var errors = []; 2 3 // Any missing params? 4 if (typeof fromAccount == 'undefined') { 5 errors.push("Missing fromAccount parameter. "); 6 } 7 if (typeof toAccount == 'undefined') { 8 errors.push("Missing toAccount parameter. "); 9 } 10 if (typeof amount == 'undefined') { 11 errors.push("Missing amount parameter. "); 12 } 13 14 // Transfer more than $10000 no permitted 15 if (amount > 10000) { 16 errors.push("Transfer amount must be $10000 or less. "); 17 } 18 19 // Any errors? 20 if (errors.length > 0) { 21 // Don’t proceed, tell calling client what they did wrong 22 return resp = { 23 "errors": errors 24 }; Để đảm bảo hơn, chúng ta có thể dùng try/catch/finally ở chỗ phù hợp để bắt lỗi trong lúc chạy thủ tục adapter. 4. Kiểm tra, kiểm tra và kiểm tra Thủ tục xử lý lỗi adapter thường dễ dàng để kiểm tra cho các cơ chế kiểm tra b adapter-liên-quan được cung cấp bởi IBM Worklight Studio dựa trên Eclipse. Studio cung cấp tùy chọn triển khai một adapter đến Worklight Studio được xây dựng trong Worklight Server, gọi một thủ tục adapter, và gọi trực tiếp một dịch vụ doanh nghiệp đầu cuối.  Viết adapter để xử lý các sự cố của dịch vụ doanh nghiệp bằng cách giúp cho các ứng dụng client khỏi phải biết quá chi tiết về các dịch vụ. Điều này sẽ giúp đơn giản hóa logic của ứng dụng client.  Bình thường hóa thông tin lỗi trả về cho ứng dụng client như việc cung cấp thông tin lỗi và mảng lỗi của đối tượng phản hồi, do đó ứng dụng chỉ cần kiểm tra ở một nơi để xác định thành công hay thất bại.  Chương trình 101: Hãy dành thời gian để thêm các đoạn mã xử lý lỗi mạnh mẽ và dự phòng trong các thủ tục adapter và kiểm tra các xử lý lỗi triệt để để tiết kiệm thời gian debug ở bộ phận đảm bảo chất lượng và bối rối trong sản xuất.