What makes an upgrade project challenging? For the most part that’s the time gap between the source and the destination versions of the system; imagine migrating from something that is 8 years old, add some changes in the data model on top of that – and you’ll get a picture of what we have recently done for one of our clients, moving from Siebel v7.8 (SEA repository) to v8.1.1.10 (SIA repository). Regardless, the upgrade has been a success, and this is a story about it.

Our company employs over 50 Siebel consultants, which yields more than several hundred years of overall experience gained in different Siebel projects across the world. When most of us started with Siebel, we felt a huge demand for Siebel consultants, and usually we had a bunch of projects to choose from. However, some time ago we’ve noticed that this demand has started to decline. So for the last few years we find ourselves quite often in discussion of Siebel future. The idea of this post is to accumulate our thoughts on the subject and see whether the whole picture starts making any sense...

Most of our clients know at least one place in their Siebel solution, where they can click and then go grab some coffee while waiting for a response. Perhaps, there are such places in your Siebel system as well? Are users telling you that Siebel is slow? And do you know how to approach those issues?

In the previous article of this series we have done Siebel configuration, as well as presentation model and presentation renderer modifications, required for the bidirectional Siebel OpenUI – Google Maps integration. In this final article, let us have a look at what remains to be done to have a fully-fledged solution.

Last time we’ve seen how to transfer address information from Siebel to Google Maps and display a location on the map, i.e. implemented a unidirectional integration. Now the time has come to make the address data travel the other way around: from Google Maps picker to Siebel, so let us see what needs to be done to make it happen!