While developing processes within SOA Suite (or other systems) it is often a requirement that the process sends an email on failure, or otherwise alerts a user (or group) that the process was not successful. This has the unfortunate side effect of easily overwhelming inboxes and frustrating users.
Figure 1: Is this your inbox after a long weekend?
This article is going to deal primarily with SOA Suite, but the techniques used within can be applied to any technology and in fact are used within several products (including FlexServices for SOA).
Basic Pattern
For those people that have seen/used the Parking Lot Patten, this approach will seem similar, but instead of throttling the amount of messages processed, we will be using this approach to batch email messages. The overview of the composite is below:
Figure 2: Basic Composite Flow
This pattern will consist of two separate pieces:
- Email Collector
- Email Processor
For this example, we will be implementing both pieces in SOA, but the processor could easily be implemented in JAVA, PL/SQL, or anything else.
Database model
Figure 3: A very simple example (not production ready)
The model above is very simple and doesn’t support much configurability, but has all the basic and essential parts. The subscriptions are so we can categorize the messages, as well as not require the calling process to know the subject line, email addresses and such. The join between the two models is the SubscriptionCode. This is because the surrogate key (ID) won’t be known at development time. Subscriptions could use SubscriptionKey as a natural key – however, future development may allow for subscription versioning, or other situations where the SubscriptionCode won’t be unique, thus a surrogate key is used to support future development. The email collector (descripted below) populates the Messages table. The Subscriptions table would be managed by a GUI (OAF, ADF, APEX, etc) or directly though database inserts – but this is outside the scope of this post.
Email Collector
For our email collector we will be using EDN. This could be a web service, JMS Queue, or really anything the composites can connect to. I’ll be using EDN in the diagrams because it gets you up and running the fastest, and is the easiest to connect to from a composite. The biggest thing to consider is what are you passing in the payloads. You don’t want to be passing an email (since these are aggregated) but want to pass content that COULD be aggregated. This could be a message that gets listed in a log type format. The FlexEmailer that Flexagon provides also allows for tabular data to be passed in – allowing the email to be formatted in a table. Obviously, there are several approaches that could be taken and the best one is going to be the one that satisfies current and future business needs. The calling system needs to pass in the SubscriptionCode and Message. The collector will write this information and the additional fields to the messages table.
Email Processor
For out email processor, we will be using a BPEL process. The timed event can be with either the scheduling component included in 12c, a homegrown solution, an enterprise scheduler, or even a DB adapter (if you aren’t concerned about timing precision or the possibility of getting multiple messages). The email processor will need to fetch the messages in a big batch, perform any HTML markup, organize by groups, and then send out the emails. The high level outline of the process is below.
- Fetch Subscriptions
- Fetch Messages    with proper polling flag
-
For Each Subscription
- Get all messages with Subscription Code
- Format Email Body
- Send email message
- Update Polling Flag
-
Find Messages without valid Subscription
- Format exception message
- Send message
At the end of this process, all pending messages will be categorized by subscription and sent out. So if there were 10 failures, instead of 10 emails, the user will receive one email with 10 messages. This aggregation greatly reduces the “chattiness” of the SOA system.
Benefit
The biggest benefit to using this approach is the reduction in email. As anyone who has ever dealt with support has found, email fatigue is one of the biggest ways issues slip through the cracks. Especially on “chatty” systems, it’s not unusual for users to create filters and rules to shuffle off the emails so they aren’t constantly alerting. After all, if every message is important, no message is important. This also reduces the changes of a system being down causing a user to get blasted with lots of email message (especially if it’s a batch job). Another benefit of this process is that the information can be organized in useful ways before sending it off. The process we created at Flexagon allows us to send tabular data, and send multiple tables in an email. This allows us to send not only error information, but other useful information (keys, invalid data, etc) so the user can act immediately, and not have to fish for critical information.
If this was useful let us know in the comment form below. If you (or your organization) are interested in a production ready system or wants to hear how Flexagon can help your company turbocharge your SOA implementation just contact us.