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.

Bill Paris, Nhà phát triển phần mềm, IBM

Bill Paris là một nhà tư vấn phát triển về các dịch vụ phần mềm của IBM trong nhóm WebSphere. Ông chuyên phát triển ứng dụng cho thiết bị di động và máy chủ trung gian.



17 05 2013

Giới thiệu

Tải về Worklight

Hãy tải về ngay phiên bản miễn phí vô thời hạn: IBM Worklight Developer Edition 5.0!

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
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.invokeSQLStatementWL.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.
statusTình trạng phản hồi HTTP (chỉ dành cho các HTTP adapters).
invocationResultLà 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 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.
statusTình trạng phản hồi HTTP (chỉ dành cho các HTTP adapters).
errorCodeMột mã lỗi kiểu string
errorMsgMộ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 http://221.16.94.228:9080 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.


Kết luận

Tóm lại, ý tưởng xử lý lỗi adapter của chúng ta bao gồm:

  • 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.

Lời cảm ơn

Xin chân thành cám ơn Karl Bishop đã đóng góp chuyên môn về các phương pháp trong bài viết này, đồng thời cám ơn các đồng nghiệp của ông: Tom Thacher, Raanan Avidor, và Gang Chen về các hướng dẫn kỹ thuật của họ.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Công nghệ Java
ArticleID=930015
ArticleTitle=Xử lý lỗi trong IBM Worklight adapters
publish-date=05172013