Advanced Siebel Integration - A SOA Review

A recent Oracle SOA review into one of my customers Siebel Integration capability, rated it as highly advanced. The innovative systems, processes, and tools that were put in place, evolved immensely over the years, and enabled the customer to build, deploy, test and maintain their interfaces quickly and with little effort.

In this organization, the Siebel team provided the front line EAI development, and supported a large portfolio of services across numerous touch points and multiple transport types including MQ, WS, File, HTTP. While adhering to architectural principles such as SOA, P2P, Pub/Sub, this Siebel system plays the role as a consumer, subscriber, publisher, and router of services.

The environment mix, architecture, and scale may differ in your organization, but there are some fundamental challenges that all Siebel Projects face.

High Level Challenges

- Simplify and standardize Integration
- Reduce Integration expenditure
- Agility and Time to market

Simplify and standardize Integration

From a high level, there are a variety of messaging requirements that we may encounter, including Request/Response, Notification, Async callbacks, Pub/sub, then we have various transports to handle, which may include HTTP, Message queues, file formats. We then have to choose between the various transformation options, and figure out how to generate our message with the correct headers, deal with message dispatch and error handling.

There are a variety of implementation options, and each developer will have their own approach to solving the above problems, which can lead to non standardized solutions, that overtime becomes difficult to maintain. Reducing the complexity, and standardising the way we implement integration requires a system that helps us to deliver a consistent solution to dealing with the above scenarios. 

A key component of this system is establishing a Siebel Integration competency centre (ICC), which acts to standardise Integration solutions. An ICC can be defined as team that is responsible for the Siebel EAI needs across different streams and projects. 

Another vital component is the integration framework. An integration framework encapsulates all common integration logic, implements standard design patterns, minimises customisation, coding, and minimize deviation from the standard design entry/exit points. A good integration framework provides the ability to integrate a lot of different technologies, and is instrumental in enabling projects to simply their Integration.

Reduce Integration expenditure

Some organisations approach integration on a case by case basis. The work is put together in an adhoc manner to achieve a certain result, and the grunt work is then repeated on the next project. Issues such as maintenance, error handing, and robustness, unfortunately is an after thought. This causes a lot duplication, waste, increases cost, maintainability, and risk.

An alternative approach is to look at introducing an integration factory. The concept of an integration factory, is not dis-similar to how car factories mass produce vehicles using standard core components, where robots perform the heavy lifting and mundane tasks on a production line, and engineers move in to perform the specialist tasks that require finesse and skill. This results in a consistent and quality deliverable, that is cost effective.

In the same way a Siebel integration factory, can delegate or automate certain integration chores, to free up the Siebel Integrator to perform more value added tasks. This factory consists of a set of tools and processes which allows projects to churn out interfaces using a cookie cutter approach to reduce integration build and test.

Under this approach, less experienced integrators can be used to safely deliver interface work, because the factory enforces a consistent approach to the build. Contrast this with an adhoc build approach, where a less experienced developer is provided with 101 ways to implement something simple like validation, and countless ways to trigger, and implement automation. We can imagine the outcome will be inconsistent, to say the least, and is likely to result in increase costs for the next project who has to maintain this work.
An Integration factory provides tools to work with messaging requirements, scaffolding for quick deployment of interfaces, and a controlled process to produce interfaces. Integration artefacts such as VBCs, Inbound, Outbound, Request/Response interfaces all have a certain flavour, and are produced with the same common components, and are orchestrated to meet a requirement. 

By applying standardisation, establishing reusable components, and using proven design patterns to solve known problems, we can reduce the cost and risk of implementing integration.

Agility and Time to market

Many Siebel projects need to support rapidly changing business requirements, and deliver on future initiatives at the same time. Integration is traditionally seen as risky, costly, and usually delegated to major releases, which limits the ability to be agile and deliver solutions quickly.

One of the keys to agility in Siebel is to keep logic out of the SRF, and fortunately Siebel provides a lot of options to configure EAI capability on the fly.

Client side business services

Client side business services allow Siebel customers to configure and deploy technical logic to a run time database. This capability allows project to change logic on the fly, and maintain a 24/7 application. There are customers that purely use Client side business service because of the agility advantages over eScript.

Siebel Workflows

Siebel workflows are the work horse of automation in Siebel, it provides a nice interface with a visual representation of customer logic. Workflows can be configured and deployed to a run time database, allowing projects to switch workflow definitions on the fly, and apply logic changes without downtime.

Business Rule Processor (BRP)

BRP was designed as declarative replacement for eScript, and allows projects to build application logic using a browser. These rules are then executed by a highly optimised engine that works beneath the Siebel BO layer to maximise logic execution. BRP rules can configured and deployed using the Siebel thin client.

Data Mapper

Datamapper is Siebel’s declarative engine that performs an object to object transformation. Data map transformations can be also configured using the Siebel thin client.

Runtime Integration Objects

Integration objects are representations of a model in Siebel, which is usually built using Siebel tools, and compiled into a SRF. However, with an appropriately connected thick client, Integration object definitions can be deployed to a run time database. When runtime Integration Objects are combined with the right mix of EAI technologies, Siebel customers can build and deploy interfaces without downtime.


Siebel provides XSLT 1.0 as standard out of the box, but customers can easily implement an XSLT 2.0 engine to get access to an expanded set of transformation options, and speed benefits. XSLT provides a powerful declarative transformation alternative to eScript or Data mapper. 

The Siebel product has a solid range of construction tools out of the box, that allow for changes to be deployed without downtime. Siebel customers that make best use of these technologies, have the opportunity to be very agile and reduce the time to market for their solutions.


In this article we’ve introduced the high level challenges of Siebel Integration that organisations  face. This prepares us for the next set of articles, where we’ll dig deeper, go through real world scenarios, consider solutions that are aligned to the principles introduced above, walk through the features of a Siebel integration framework, and address the following low level challenges.

- Reducing technical burden
- Dependency on external interfaces
- Working in disconnected environments
- Working within constraints of Siebel product
- Reduce scripting and hard coded references
- Improving code quality 

Oracle Siebel Open UI Developer's Handbook Review

Not so long ago, I received a book in the post from our good friends from Oracle (Ford, D & Hansal, A & Leibert, K & Peterson, J, (2015) Oracle Siebel Open UI Developer's Handbook: Oakamoor, P8Tech). I spent a weekend scrutinising the book and came away thoroughly impressed. So here is my perspective of the book.

As one of the early adopters of Siebel Open UI, I had to learn the product quickly, train internal  developers, and establish a build process for working with this new technology.  The tools, scaffolding, processes and Open UI knowledge was then passed onto the next generation of developers.

A lot of effort was put into establishing this internal competency, as it was done at a time when knowledge of Open UI was scarce, Open UI instructors were themselves being trained, so the best way to learn was to look through the source code, and browse the API tree using the browser console. 

Now days training can be arranged quite easily, there are numerous blogs that spread Open UI knowledge, and you could still learn a lot by looking at the source code, so does this new book add any value? I contend that the "Oracle Siebel Open UI Developer's Handbook" provides significant value for the serious Open UI developer.

"Oracle Siebel Open UI Developer's Handbook” is a comprehensive book, and its likely that you’ll need to read over many times to really gain benefit from it, there are sections that you’ll skim over because it may not be relevant in your current role, but its comprehensiveness is part of its broad appeal. The book covers Open UI basics, manifest, PM/PR, architecture, installation and deployment, visualisations, CSS themes, advanced scripting, integration and even mobile development. 

Much has changed since I delved into the product that was then IP2012. The whole development team was sent on Advanced Open UI training, and since then only a handful of lucky people got to work with the technology. The half of the team that actively works with the technology are certainly more skilled than the other half that hasn’t use their training. This book  appeals to both markets, as it is aimed squarely at the developer, and doesn’t make any assumptions about the level of the reader.  

Siebel projects around the world would have a similar mixed bag of Open UI knowledge. IP2012 is now superseded by IP2013, and IP2014 and the product has evolved quite drastically, so your skills might not be where you think it is. This book provides a great chance for Open UI professionals to learn the latest developments from the Open UI product or solidify their existing knowledge, without going through further training.

Alternatively developers can invest a bit of time going through bookshelf, and trawl through all the articles on the web to self learn Open UI, it is certainly possible, but learning Open UI is not a natural stepping stone for many Siebel developers, and for the seasoned developer like myself, who is quite time poor, I found the book to be an excellent investment of my time, and wished I had it when I first learned Open UI.

This book adds great value, as you learn Open UI from the 4 of the best Open UI experts in the world. If you like @lex’s work on Siebel Essentials (Siebel Hub), then this book is more of the same awesomeness, but packaged for the Open UI professional.

Get it here from Amazon