In this installment of the series, we will be looking at how to identify what services should be made common or enterprise services. We will cover the usual suspects, as well as services that may make sense to make common within an organization.
The Usual Suspects
The big three services that are typically developed as common services are Error Handling, Logging, and Notifications. Depending on the platform some of these services may either be implemented, or there may be enough coverage to not warrant a full blown service implementation. For instance, on the Oracle SOA Suite 12c platform there is a fairly robust notification framework, so building out a full featured service may be unnecessary – though building out some facilities to help developers may still be a worthwhile effort.
Error handling is one service that is easy to do wrong, but rather difficult to do right. A lot of error handlers we’ve seen built have had one of two problems, either it was so basic as to be useless, or it was so complex the handler could break. With that in mind the following “rules” should be followed when designing or building an error handling service
- The error handler should not fault or break
- The error payload should be easy to generate
- The configuration should be simple to setup
- ALL fields should be optional
- Never assume an error going to the handler has ANY correct data
Points 1, 4, &5 are all interrelated to the central notion most people who develop services forget…. The handler is being called because SOMETHING WENT WRONG! If everyone does their job, the handler will never be invoked, the fact it’s being called indicates there was a failure somewhere along the way. By requiring certain fields, or making the handler not sufficiently robust it is possible to have the error handler get an error. By building the handler to not fully trust the data, you have to build the handler to be smart enough to handle incomplete or bad payloads. It’s a little more work, but it’s less time on call fixing issues.
When developing the error handler, one thing to think about is what should be the outcome – and what are the possibilities. As part of FlexFoundation for SOA, our handler can do several different things to handler errors – with one of the most important things being to hand off control to another program. This is important, as the handler should be able to handle a lot of the simple use cases – but more complex behaviors should go to a dedicated program. This enables flexibility as well as a far richer solution.
Out of the box, most solutions provide facilities for logging – though a lot of times it is more geared towards admins and not business users. The logging this article refers to is more business logging. Our service logs to a database much like the FND logging that is done in Oracle E-Business Suite. This enables us to have a nice GUI for BA’s to view, and means Admins don’t have to shuttle logs to users. This service can be implemented either as a composite or as pure code. In our product we utilized a custom XPath function. This enables the logging to be efficient as well as easy to call. If logging means having to call a web service, set up variables, and such, it just won’t be used. By making logging simple and tunable, it increases the odds it will be leveraged – AND – make it easier to use and understand. A few things to keep in mind:
- Who is the audience?
- What is their skillset?
- How is the log level controlled?
These questions will help guide what a service eventually looks like.
Notifications can be a tricky service to create, as different projects may have different standards. Typically, when referring to notifications, we are really talking about email – though in 2015 we could also be referring to SMS or IM. One big thing to consider is whether or not a notification system already exists. Maybe the common service interfaces with an existing system. This would make the service simpler and help not getting stuck in the weeds of what a notification should look like. Designing a template and/or look and feel will probably take more work than the actual programming for the notification service. Some questions to consider:
- Is there an existing notification system we can leverage?
- What should the look and feel of the template be?
Are there any stakeholders that may need to be involved?
Once requirements have been gathered, the actual design and development can begin. Typically, this will begin with building out the data models. One of the big points to remember is to keep things simple. Making any of these services too complex, will limit their usefulness and reduce the odds they will be adopted and utilized throughout the organization.
In the next chapter of this series we will be covering the data model in further detail. How to design a good data model and what pitfalls to avoid.