Siebel IP17 – Statement of Direction


It has been released, the yearly ‘Statement of Direction’ – for many regarded as a ‘State of the Union’ for Siebel – for the release to come. That will obviously be Innovation Pack 2017, to see the daylight around April/May next year. John Bedford posted on Oracle OpenUI blog last week about it.

The full details can be found per usual on Oracle Support:

Innovation Pack 2017 (17.0) for Siebel CRM Statement of Direction / Planned Features (Doc ID 2179185.1)

For sure, Innovation Pack 2017 first and foremost is focused on Siebel Composer, Siebel Composer and again Siebel Composer. The one and most import design theme, at the roots of Siebel as we have known it over the past two decades. IP15 and IP16 have presented ‘developer previews’ and after two years in infancy, innovating and maturing – it will be the real deal in Innovation Pack 2017. And no, Siebel Tools will not cease to exist – and a lot of activities will still be managed through Siebel Tools. Scripting, Workflow, Incremental Repository Merge, … it will remain in Tools. Don’t be fooled.

The Workspaces – no-more-local-database – introduced with Innovation Pack 2016 will become default. And for that Workspaces will be enhanced to allow for full multi-level branching, to support parallel, multi-release development. I say will allow because it certainly will require very strong governance, not getting lost at the same time. Governance and overseeing ongoing developments will become even more important than it’s today. So: Lead Solution Architect: be prepared!

Composer and Workspaces lay out the foundation for agile development with Siebel better than ever before. But agile development also requires (regression) test automation, ideally on a daily basis. It has always been the Achilles’ heel and never an easy task, relying on 3rd party software such as Oracle’s Application Test Suite. Since a couple of years Oracle has been using internally a Selenium-based solution for regression testing of all OpenUI applications using a Keyword-driven framework build around Selenium. This has matured and it’s good to see it surface in the Statement of Direction. It will create only a loose dependency with Selenium, where all test scripts/suites and executions are managed and stored in the Siebel database.

And yes, Siebel becomes elastic where finally one would be able to dynamically provision a new Siebel Server in an up-and-running Siebel enterprise at zero-downtime. Though this feature is reserved for customers deploying on Oracle’s Public Cloud infrastructure.

To close off, Siebel REST API will be enhanced to support Swagger for service description. As well, REST API will be more dynamic in terms of ability to describe on the request the needed output (e.g. child entities and fields required). Great!

– Jeroen

PS: This might become my final post on the Oracle Implementation Advisor Blog…









5 thoughts on “Siebel IP17 – Statement of Direction

  1. so composer is not a replacement for siebel tools?i was surprised to see here that Scripting ,workflows are still going to be developed from tools.i know in the past that schema changes like table/column extensions were going to be done via tools but now i am hearing that scripting and workflows going to still exist in tools?

    so we are not essentially moving away from SRF compilation and such…that would be confusing for developers as to what goes where etc…


    • Hi Rao,

      Composer will not be a replacement for Tools, that’s right. But yes, we are moving away from SRF compilation – that is a separate topic if you like, and has little to do with composer versus Tools. Even a change done via Tools (e.g. a script change) with a workspace will be part on the run-time. Don’t forget why the SRF exists, because in the far past is was the most efficient means to represent and load the repository by the object manager, instead of crawling and querying endlessly through the repository (that is what a compile essentially is, right). A repository file will likely exist still in IP17 going forward, but not a deliverable you’d need to worry about – but build in the background, because still it will be the most efficient way for an OM to load/startup. How it will in detail work in the end, we’d need to wait for a bit more 😉

      • Thanks for your reply and detail explanation of the SRF and its role going forward.
        But,still it doesn’t make sense to me why you would need to perform tasks in Tools for scripting and workflows.we all know that scripting editor in siebel tools is rudimentary and this was a great opportunity for them to rewrite and build more intuitive IDE.same goes with Workflow editor too.i feel that they missed the opportunity at least for now… don’t know if there is such a plan in the future though.

        Thanks again for your valuable insight on the topic.

      • Hi Rao, it probable is a risk/reward/investment decision. It would be great, sure – to have 100% composer-based development for everything we know of today. But porting 100% of the functionality from the W32 Tools client to a web-based application should be considered a immense task. I could imagine that workflows/tasks transition back to a composer-mode way of working. Especially because it’s visual-oriented, I’d reckon too that re-building ‘simulation’ should be a do-able task with serious benefits.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s