![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |
The TIBCO Adapter SDK has its own MException class.The C++ MException class differs from the standard C++ exception classes in that it does not use a different exception subclass for each type of exception. Instead, MException encapsulates exception information, including an exception code, to avoid a large number of exception classes in the SDK. See the TIBCO Adapter SDK Message Codes for more information.Catching an MException instance is similar to catching any other C++ exception. MException accessors allow the custom adapters to access the encapsulated information. Comparison and assignment operations are also available. It is possible to get a verbose description of the exception. See MException in the C++ API.An MOperationException class has been defined for use with the SDK operation model, which allows custom adapters to perform operation invocation or to act as an operation server in a client-server implementation. Custom adapters do not create instances of MOperationException, they only retrieve error information from it. See TIBCO ActiveEnterprise Operation Model.The SDK supports standard Java exception handling. The Java API includes an MException class with subclasses that indicate different types of exceptions. Each class is documented as part of the API documentation.Java custom adapters can use the instanceof operator to find out the specific error that occurred. If the custom adapter wants to print the error to stdout, it can call the getMessage() method from the exception object to retrieve the message string.Figure 14 SDK MException Class HierarchyA custom adapter can catch exceptions thrown by the SDK and handle them appropriately. Custom adapters can also create their own subclass of MException for application-specific exceptions.
− When an operation fails due to business logic execution, it should not prevent the adapter from continuing to function normally. The adapter must anticipate and handle business exceptions. You should also consider the possibility of receiving data that does not match the expected metadata description.
− For programming mistakes, the adapter must ensure that there is enough information traced and logged for an administrator to debug or work around the problem.
− Business errors can be handled outside the adapter (for example, in TIBCO ActiveMatrix BusinessWorks).
− A business exception handling mechanism within the adapter is also possible. However, such design could compromise the flexibility of the adapter to evolve over time as business requirements change.
− Hawk can help monitor and manage the adapter using a Hawk trace sink at runtime. Hawk can also be used to restart an adapter in case of fatal system errors. Hawk sends out alert message, email, or a page to an administrator who can correct and bring the system back up if needed.
− TIBCO Administrator implements monitoring and tracing behavior. You can also write trace information to files.
− Transactional messaging behavior provided by TIBCO Rendezvous TX includes atomic transaction, exactly once message consumption (duplicate detection), and store and forward message delivery.
− You should ensure that the adapter can survive system errors such as a target application down. Message integrity must be preserved in case of system errors.
− By wrapping a transaction around both the consumption of the incoming message and the publication of the resulting transformation, the engine is made lossless. That is, a message is never marked as consumed until the transformed version has been successfully published. Similarly, no transformed message is published until the incoming source message has been marked as consumed.
− All known system and business exceptions should be handled. Logging and monitoring can help manage other disaster scenarios.Delayed acknowledgement of a certified message is also known as explicit RVCM confirmation. This feature is most useful when controlling whether to confirm receipt of the certified message. This feature also allows you to handle the case where a target application crashes after it receives a certified message, but before it can process the message.Note that successful certified message delivery is different from successful application processing of the received message. Adapter business logic and application error (not application crash type) handling logic should be separated from explicit RVCM confirmation.Adapter developers must decide whether the adapter should acknowledge messages that have resulted in an error.
• Data errors If the message is retransmitted, it will probably result in the same error. This may not always be true if the operation failed due to missing information that may subsequently have become available (for example, a foreign key violation).
• System errors The message cannot be processed because the target system is down. The message is retransmitted after the system comes back up and the message may then be successfully processed.Second, being a message delivery protocol, RVCM has no built-in intelligence to retransmit on a failure condition at application level. RVCM should not be used to recover or retransmit after an error condition, such as failed operation invocation.
• When the receiving certified subscriber detects a missed message from the sequence number. For example, the receiver gets message # 1,2, 3 then 5. The certified subscriber will request retransmission for message # 4.
• In recovery from abnormal termination of either the publisher or subscriber. For example, a certified subscriber crashes while the certified publisher keeps publishing. When the subscriber is restarted, the messages published while it was down will be retransmitted from the publisher.Messages that result in data errors should be acknowledged (confirmed) and logged, which allows the problem to be addressed outside the adapter.
• Explicit RVCM confirmation can be used and the adapter can simply not acknowledge a failed message. However, the adapter must manage pausing and triggering retransmission of the message so that it can be resent for processing.The Adapter SDK provides a subscriber method that allows custom adapters to suspend and restart certified message delivery subscription. The MSubscriber::suspend() method stops the current subscription interest but does not cancel the certified delivery agreement. The suspend() method works the same way as an abnormal termination of subscriber, mentioned above. By suspending subscription interest the publisher retains all the certified messages it publishes.When the target application is reconnected the subscriber can resume subscription and the publisher will retransmit all messages retained. Subscription interest is restarted by calling the MSubscriber::activate() method. There are no equivalent methods for the request response service, you should instead use the operation remote exception handling mechanism (that is, confirm and raise remote exception).
• If the subscriber application is a stateless, short-lived process, sending the RVCM confirmation at the end of the process is acceptable. Otherwise you need to persist and confirm, then do the processing. If a system error occurs you should recover using the persistence.Either way, you must deal with the possibility of a continuous system error (that is, the target system is never reconnected) and should handle it like any data error.
![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |