Asynchronous Workflow With Real User Login

Background

A common requirement amongst many Siebel customers, is to have the ability to run an asynchronous workflow under the real user's login.

This issue is highlighted in the following Oracle support web document, and is representative of the problems faced by many customers.

NOTE:494815.1 Setting CREATED_BY to the user that invoked the workflow process asynchronously

The customer stated that they have an asynchronous workflow, and wanted to know if it was possible to set the creator login of a server request. The solution offered by the support personnel was to run the work flow in synchronous mode.

Asynchronous workflows are used in Siebel to offload work from the user session to perform background processing, however that leaves an undesired effect of stamping the record with SADMIN. This behavior obscures information about the creator, updater, and prevents audit trail from being utilized.

Workflows can be run synchronously as suggested in the Oracle support web document above, but it has the rather unwanted effect of blocking the UI.

Fortunately, for customers who can't accept running background tasks synchronously, there is a viable solution, but it requires a little bit of effort.

Requirement

To re-affirm the requirement, we are going to walk through a solution that allows any workflow or business service in Siebel to be run asynchronously, under the actual users credentials, and without actually supplying the password!

If we step back, and look at the problem from an architectural perspective, we know that when the user logs into the Application and executes any type of code such as eScript, or workflow, it will run synchronously under the users application object manager, and it will operate under the users own credentials.

The only supported method to run code and avoid blocking the UI, is to run code under a background process, however any code that is run in the background will operate under SADMIN by default.

The first challenge is to find a supported method to execute code in a background session under the current users credentials. Experienced Siebel Integrators in the audience can probably guess, that we can achieve this with any Siebel API that supports SSO, or utilize the inbuilt impersonation capability of certain Siebel components.

The two most suitable choices are:
1. Siebel WS
2. Siebel JDB

I've highlighted these particular interfaces, because both provide APIs that can be invoked from a background session, and has the potential to allow arbitrary code to be dispatched, and run under a different set of credentials. As an added benefit, both of these APIs can be built to support load balancing for high availability.

With a suitable SSO API identified, we have the necessary key piece required to solve the above problem.

Solution Overview

The diagram below shows an overview of this proposed solution.

1. The user triggers an asynchronous task from the current user session, and is allowed to continue with their work in the application

2. In the background, A WFProcMgr component on the server executes the process, and calls a bespoke service called "JLE Session Transport Service" that acts as a wrapper for the transport.

3. A synchronous call is invoked over the transport, using the Siebel API identified above

4. The Siebel API instantiates a new session on behalf of the real user, executes the destination business service, and returns the results back to the background process.

Siebel API

An important implementation aspect worth considering upfront, is designing a transport agnostic API for the Siebel developer. The developer should be able to specify the desired subsystem, and the service should abstract the low level transport requirements, and perform the necessary acrobatics to make the call.

The following diagram shows how a facade is used for invoking the actual SSO interface.

A standard Siebel business service is defined, so it can be substituted in any existing workflow, or hooked into any existing Siebel trigger. The designer now has to implement the adapter code, and build the interface to communicate with the relevant SSO interface.

The implementation of interfaces to these Siebel APIs are out of scope of this article, as it requires different spectrum's of design, involve advanced integration, and require environment dependencies to exist, but the key considerations are provided below for customers who are interested in building this capability.

Depending on which SSO API is chosen, you may require an Integration specialist to implement a WS/BS dispatch wrapper, or a Siebel EAI/Java specialist to implement the Siebel-JDB bridge.

Please consult with your Siebel Integration Architect for more localized implementation advice.

Input Arguments

To support a plug and play design, I propose that all input arguments and child properties passed into this service would be dispatched to the remote business, in the same way as any other business service in Siebel including workflows.

This design allows us to go into tools, and retrofit this capability to any business service, without redevelopment effort. It is also deliberately designed to avoid hierarchy changes required for the correct invocation of the destination business service.

To control the dispatch, lets define a custom child hierarchy, which contains 3 key elements.

1. The user login to impersonate
2. The destination business service to dispatch to
3. The destination business method name

The diagram below illustrates the property set structure, with the required information to dispatch the call



This special PropertySet can sit at any index, however it should be removed before it is dispatched to the remote business service, in-case there is logic that is sensitive to property sets with specific indexes.

PropertySet Serialization

PropertySets are a Siebel proprietary representation of objects that only exist in memory. In order to send a PropertySet out of Siebel, and receive it back in, it has to be serialized, de-serialized, and potentially encoded to match transport constraints.

XML is usually used to transfer data between different systems, and Siebel provides methods to convert the PropertySet to XML, and back, however a more efficient method is to utilize Siebel's own PropertySet to text encoding format, or a utilise a custom JSON parsing engine in eScript. This minimizes the size of the message, results in less IO, and ensures that request is sent as efficiently as possible.

Error Handling

This is the most critical aspect of the design, as every component in the design has to be proactive in handling, and bubbling errors back up the chain.

The caller is effectively making a synchronous request/response call between two sessions. Errors at the end of the chain in the impersonated session, has to be propagated through the transport, to the calling session, which has the responsibility to handle and log any errors.

It is imperative that each component have guards in place to handle environmental, transport, and general unhanded exception scenarios, which could cause the call to fail.

This can happen for a variety of reasons including

Component is offline
Component Maxed Task
Connection timeouts
Failed authentication
Out of resource

The Siebel JDB interface has OOTB capability with extra options for configuring, settings such as retry, and timeouts, to counter some of the above issues. Customers choosing the Siebel WS API will have to consider implementing the appropriate mechanisms to guard against transient errors.

Load Testing

Both the Siebel WS, Siebel JDB options can be configured for load balancing through virtual server definitions. This capability allows this solution to scale easily. In practice this only works natively for the WS option, the JDB interface seems to only get load balanced if sessions are spawned from the thread. An as alternative, the load balancing responsibility for the JDB interface can be offloaded to the SRProc component.

Its important to understand the current expected load, and forecast the expected number of tasks that are needed. Every invocation can potentially spawn a new session, which could effectively double the amount of threads that the system has to spawn, along with the increased resource utilization, so it would prudent to involve your performance test team, and environment specialists to ensure that the application is tuned to handle the extra load.

Maintaining Impersonation

One last consideration in this design, is that once the user dispatches the work flow to be picked up in the background, no part of the invocation chain is allowed dispatch to another server process.

The impact is that the developer needs to ensure that all work flows are run inside the impersonated object manager. If a server request is initiated, that would then dispatch to a server thread, breaking the impersonation for that particular thread.

Conclusion

The above capability was designed and delivered for a customer who needed to meet regulatory audit requirements, to capture the identity of the users when they performed bulk CRUD operations across the application.

In the past customers who needed to meet this requirement would have chosen to take a hit in performance, and kill the user experience, while expensive background operations are forced to run in the foreground, or resort to creating extra columns across entities in the application to separately capture the identity of the user.

With a little bit of effort, Siebel customers now have the option of creating a custom impersonation component, that can run asynchronous tasks under a real user.

Read More >>>

Open UI: Protocol Handler

Getting rid of Active X usage is a priority on Open UI projects, because it allows Siebel customers to embrace more modern browsers, and remain compliant into the future, but one of the last bastions of Active X support in a Siebel Open UI project stems from a requirement to launch executables inside an internal domain.

Launching a program on the users local machine, requires browser script code similar to the following to be implemented.

var sCmd = "notepad.exe text.txt";
var shell = new ActiveXObject("WScript.Shell") ;
shell.Exec(sCmd);

As part of an Open UI upgrade review to remove browser script, I recommended to a Siebel customer that they implement a custom protocol handler to get around the above dependence on Active X.

Protocol handlers are cross platform, and are supported by the major browsers. Although the term protocol handler is obscure amongst general users, its usage is quite prolithic. Here are some common examples of protocols which are handled by browsers

http://
https://
ftp://

The above protocols are trapped and handled internally by the browser, while other protocols are passed down to the OS to be handled by the default program.

mailto://
itmss://

When mailto:// is typed in to the browser address bar, it launches the default program which is registered to handle emails. Apple users will also recognize the second protocol itmss://, as it is used to launch iTunes, the subtle suggestion here is, we could use the same technique to launch any executable.

Each platform has its own method of implementing protocol handlers, so if you are lucky enough to support mac users on Siebel, you’ll need to look into the appropriate vendor documentation. The MSDN reference provides a good digest for those wanting to implement protocol handlers in windows.

https://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx

To implement a handler for a new protocol named jle://, a simple reg file can be created and imported to into the registry.

Windows Registry Editor Version 5.00
 
[HKEY_CLASSES_ROOT\jle]
@="URL:jle protocol"
"URL Protocol"=""
 
[HKEY_CLASSES_ROOT\jle\DefaultIcon]
@="C:\Apps\protocol_handler.bat"
 
[HKEY_CLASSES_ROOT\jle\shell]
 
[HKEY_CLASSES_ROOT\jle\shell\open]
 
[HKEY_CLASSES_ROOT\jle\shell\open\command]
@="C:\Apps\protocol_handler.bat" "%1"

Replace “jle” with your own protocol, and substitute the path to “protocol_handler.bat” according to your local path. “protocol_handler.bat” is a test file that can be used debug the arguments, to see what gets passed to the invoked program, but you may want to use something more sophisticated than a batch file.

rem protocol_handler.bat file
@echo off
echo %1
pause

Once thats setup, type the the new protocol + program arguments into the browser address bar and press enter. Here’s a screenshot of the protocol handler in action.

When designing the protocol handler, keep in mind that you may want to implement a lookup system, to maintain the flexibility of invoking different programs, without having to register new protocols.

This approach was used on an Open UI upgrade to negate the dependence on ActiveX in IP2012+. If you are looking to solve similar requirements on your project, it is important to keep the following points in mind.

Pros			Cons
No Active X Works across all browsers, and platforms Does not need elevated privileges Launch only registered programs			Requires desktop deployment Requires non Siebel expertise

Read More >>>

The Harness: Use Cases

• 
• 
• 

The Harness is a modern Siebel development tool, that was built to help a customers Siebel development team to maximize their efficiency, by reducing the amount of time that is lost through the build, compile, and unit test cycle. It was developed off the necessities of integration development, and evolved from some essential use cases.

The Harness is deployed as part of the standard developers tool set, and is currently available to all integrators, configurators and production support staff, along side other necessary tools such as database clients, XML/code editors, source control tools.

It has been about two years since the first alpha version was built, and it has matured into a product that is used for development and production support.

The Harness was originally introduced to readers, in The Harness, and subsequently in The Harness Case Study, in this article, we go through the use cases, and provide videos walk-throughs of common usage scenarios.

Use Case 1 - Expression testing

Siebel expressions can be found universally in Siebel, but they can be notoriously difficult to troubleshoot.

For complex expressions, it is easy to make a mistake, leave out a bracket somewhere, or mis-spell the reference to a field or function, and when Siebel expressions are configured incorrectly, they famously error out silently. This adds significant overhead to the development process, because each change has to be iteratively compiled into the SRF.

The Harness provides an Expression module, that allows developers to simulate expressions in real time

The Harness	VS		Vanilla Siebel
Provides the ability to simulate Siebel expressions in real time Supports documented Siebel expressions Supports undocumented Siebel expressions Supports BC Field, and WF property notations			Expressions cannot be simulated in Siebel

Use Case Video: Expression Tester - Fun with Timestamp
https://www.youtube.com/watch?v=JNH6CnGbAGU

Use Case Video: Expression Tester - Lookup Function
https://www.youtube.com/watch?v=w26Ae9Tnfjc

Use Case 2 - Run eScript on the fly

One of the pain points of Siebel development, is the need to make iterative changes to eScript, which requires the developer to compile the changes into the SRF, launch the thick client, and execute the code to build and unit test code. This is another task that adds significant development overhead.

The Harness allows developer to build and test eScript on the fly.

The Harness	VS		Vanilla Siebel
Write, test eScript on the fly using a web browser Supports ST and Non ST Script engine Supports custom script libraries eScript can be run locally, on the server, or asynchronously Code indenting, highlighting, JS code hints for Non ST engine Library feature integrates with JSDoc comments for documentation Code can be generated from predefined templates Can be used to inspect runtime object variables			Traditional eScript needs to be compiled into the SRF, re-triggered, and retested after each change Developers also have the option of using the notepad like client side business service editor

Use Case Video: Script Module - Run eScript on the fly
https://www.youtube.com/watch?v=jERcYcguYXA

Use Case Video:  Script Module  - Library Search
https://www.youtube.com/watch?v=KNaSWYiIAfo

Use Case 3 - A modern Business Service simulator 

The BS SIM module provides the ability for developers to simulate business services with current application context.

It also provides modern features such as auto complete, and input property helpers, that makes testing Siebel business service behavior much more fluid.

The Harness	VS		Vanilla Siebel
Auto-complete data for business service names, and business service methods. Auto-complete data for business service input arguments, workflow process inputs, and BRP Process inputs Supports Siebel expression notation Converts XML into SiebelMessage/PropertySet/Hierarchy, as an input into the service Simulate any business service with current application context Can be configured with project specific form prefills Test cases can be saved, restored and persisted between sessions			Using Business Service Simulator the developer has to click new record, open the Pick applet, and use a wildcard search to get the service name, or method Similarly for input property name/value, the developer has to click new record, open the child applet, click new record, and enter in a each name/value pair No input property argument is provided Complex hierarchies has to be manually constructed, or shifted from the back of another business service invocation Simulation only works under the Business Simulator BO Test cases history is not available in the UI, it has to be saved/restored from a file system location.

Use Case Video: BS Sim Module - Autocomplete Fields
https://www.youtube.com/watch?v=xdZKsg4T1kQ

Use Case Video: BS Sim Module - Form Prefill
https://www.youtube.com/watch?v=Y0lsRU9hNEs

Use Case Video: BS Sim Module - History, with eScript generation
https://www.youtube.com/watch?v=umfnsBAGaXs

Use Case 4 - Manipulating the data layer

The BC module provides a tool for the developer to interrogate the configuration behind the current view, as they navigate the Application. The Harness automatically detects the application context, and pre-fills the necessary the form fields to manipulate the current record.

This module a provides developers with the ability to create, update, delete, and query for data behind the UI.

The Harness	VS		Vanilla Siebel
Detects UI context, and allows CRUD operation with a web UI Supports non UI context objects Tools configuration is exposed through the BC module UI			Developers have to use a combination of "About view", a SQL tool, and Siebel Tools

Use Case Video: BC Set Readonly Field
https://www.youtube.com/watch?v=mu5hJvqyl9I

Use Case 5 - Learning the Open UI API

The OUI module provides the Open UI developer with a web UI, that integrates with the Siebel session, displays information about the current Screen, View, BO, BC, Applets, and controls, and allows developers to drilldown into the OUI API.

Commands can be executed against the Siebel session using the inbuilt console, and the auto-complete box allows the developer to quickly search through multiple levels of API name spaces, and custom libraries.

The Harness	VS		Vanilla Siebel
About View with object inspection Learn the Open UI API by browsing on screen objects. Console with access to the Siebel session Indexes and provides auto-complete search for multiple script libraries Automatically probes and displays information, from methods that return data			Developers can manually look at source code, or memorize documentation Open UI developers still have to use About View", and lookup the corresponding configuration in Tools

Use Case Video: Open UI API Browser
https://www.youtube.com/watch?v=n-CLyrc_YA8

Other modules

MQ/HTTP Module

The Harness originated from this humble module. The MQ/HTTP module is an essential module for Siebel EAI/middleware developers. It provides a real time interface for sending/receiving messages across message transports. This specialist module provide important prefills on transport parameters, and message templates, that can be used to quickly setup data, and interrogate interface behavior, with XML aware syntax highlighting.

IO/Msg Module

The IO/Msg module is another essential tool for Siebel EAI/middleware developers, that allow messages to be generated, inspected, upserted/inserted/synchronised and converted on the fly.

Server Health Module

The Server Health modules probes the server to provide important information such as the machine that the session is connected to, server disk, memory, and CPU utilization. This has been found to be useful in pin pointing problems in resource constrained environments.

FAQs

Does it work with HI/Open UI?

The Harness was originally designed to work in HI, and has since been ported over to Open UI.  It has been tested against HI 8.1, OUI IP2012, IP2013, IP2014, IP2015

Does it replace Siebel tools?

No. The Harness augments Siebel Tools, however depending on the role of the developer, they could spend a significant part of the day in The Harness testing interfaces, and writing unit test cases, reverting to Tools to create the necessary foundation objects.

How long does it take to build such a tool?

2 months to build an alpha version from scratch.

What kind of skill set do I need to build this tool?

Siebel professionals with expertise in eScript, Web professionals with strong JS, UX, and Java is also helpful

I would love to have it as part of my collection, can you send me a copy?

Unfortunately for third party Siebel tool collectors, The Harness is an internal product.

Where can I download it?

The Harness cannot be distributed in its current form.

Can I trial The Harness?

The Harness doesn't have a trial mode

Can I take this tool onto my next project?

The Harness contains specific customer code, and integrates tightly with a client library. Key parts of the program has to be ported, and a suitable core library has to be established, for it to be used on a new project.

Contact me on Linkedin, if you are interested in knowing more.

Read More >>>

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.

XSLT

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.

Summary

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 

Read More >>>

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

http://www.amazon.com/Oracle-Siebel-Open-Developers-Handbook/dp/099291051X

Read More >>>