Achieving Digital Transformation with Oracle's Siebel CRM

Innovation Pack 17.0 FAQ - Composer

John Bedford
Director, Product Strategy

Composer & Workspaces FAQ

1. How will Siebel Composer (Web Tools component) co-exist with Siebel Tools, it seems Tools will still be required for certain object types)

Essentially both Web Tools (a part of Siebel Composer) and Siebel Tools are just windows to the repository for configuration purposes; both give the ability to see a specific Workspace.

2. What server script debugging is available in Web Tools?

Debugging features for scripting will likely be added in future enhancements to Web Tools post 17.x. Siebel Tools will continue to be available for such purposes until we have feature and functional parity with Web Tools, in the same way in which HI mode was only recently retired when Open UI had like for like functionality.

3. Is Browser Scripting going away?

Browser scripting is not going away - but Physical Renderer (PR)/Presentation Model (PM)/Plug-in Wrapper (PW) are far more powerful alternatives. Server scripting remains unchanged.

4. Are there any objects that are not yet part of Web Tools but are still part of traditional Siebel Tools? what are the limitations with the Web Tools in 17.0?

Workflow Designer and Task Designer are a couple of examples of items that are not fully migrated to Web Tools. Siebel Tools will remain available for these development tasks until parity is achieved with Web Tools.

5. Workspace vs Repository, what's the difference?

A Workspace is, effectively, a version of the Repository

6. Is a Workspace similar to the sandboxes in Oracle Sales Cloud?

Yes, but more advanced.

7. If I extend table, how does it work without a real time schema change in the Database?

There are some controls over Database operation, certainly for additive changes, there should be no conflicts as Workspaces are aligned with the schema

8. What about List of Values (LOV) are they part of the Workspaces and versioned with them?

LOV is version controlled via Workspaces in IP17.

9. Is every configuration going to be versioned by Workspaces?


10. Workflow Policies and Schema changes, without applying them or generating triggers how can anybody preview?

There is still a requirement to have a development system separate from real-time production for Workflow Policy development.

11. Does the Workspace icon always show up in the application for the end users?

No - only if users have access

12. Where do we change the themes? Is this done directly in application?

Themes still work the same as now, so that's using manifest to add CSS - and CSS to modify. In addition - web templates will be available in-application to be modified in IP17.

13. Will CSS also be added into the repository and accessible in the application like Web Templates?

This is likely to be a future enhancement. It's important as PR/PW/PM/CSS all need to be version controlled.

14. Is Siebel Composer and the deployment tool ready for Production use in IP17?


15. Are JavaScript (.js) files included in Workspaces?

Not in this release - it's on the roadmap though, however there are tools to assist with migration of JS content. so js deployment does not go through this approval process only tools changes.

.....Even if we manually versioned these files using SVN or ClearCase?

If you have your own control system for change on JS files, that's not affected

16. Can we deploy the SRF changes without any downtime by using Workspaces?

In IP17, there is no SRF, and configuration changes deployed by Workspaces can be achieved with zero downtime.

17. Do we need to perform a manual code merge with Workspaces with parallel development?

      Merging is part of Workspace Management.

18. Scenario: I have Release 1 which goes live on March 2018 and has 2 integrations. I have started development for it in a development environment, can I work on another release which is targeted for July 2018 that has enhancements to the same 2 integrations (same objects) in February timeframe?. Then I would have 2 Workspaces. If I am constantly modifying the 2 work spaces for bugs, how are the separate changes in the 2 Workspaces synchronized with each other?

Perhaps it helps to understand that integration Workspaces can contain integration Workspaces, we didn't artificially limit that to one level deep; Workspace syncing is all about publishing / conflict resolution, and potentially rebasing, there's nothing special about that for this scenario

19. Are the objects that are moved to the new Web Tools, removed from Siebel Tools? If not will there be a synchronization issue if a developer changes the same object in both the places?

You can use Siebel Tools in parallel – there is no chance of conflict; both are just windows into the repository configuration

20. Does Siebel Composer eliminate the need separate Dev/QA/Prod instances?

It doesn’t affect decisions to use separate environments. These decisions are normally based on access to live data, rather than configuration environments.

21. From a data privacy/SOX perspective, we would want to keep a Production instance completely separate from developer access.

     This is fine, no problem.

22. With the new Web Tools, does the development database still need to be case sensitive collation?

Using Web Tools doesn’t impact your choices about case sensitivity

23. So all the changes done through Siebel Tools will also be tracked under Workspaces, or no more Tools?

Changes are tracked in a Workspace, whether you use Siebel Tools or Web Tools

24. I'm presuming multi-release development will be limited by adhering to a common database schema, workflow policies, active tasks, and active workflows. Ultimately it's sharing the same database instance.

Not necessarily - additional schema changes will be aligned with configuration - destructive schema changes are not normally considered anyway

Yes, that is correct, parallel development means you need to adhere to a common schema or ensure the schema is additive in nature which means, it supports backward compatibility as well

For the most part, except for custom tables, customers will need to adhere to additive schema only since Database extensibility restricts customers to making additive changes only for the Siebel CRM shipped schema

25. Are there any built-in code review features available, will debugging eventually move into Web Tools too?

Debugging will still require the existing Siebel Tools. Server and Browser Script written within the repository can be reviewed as part of the Approval Manager process.

Until JS/CSS moves into the database, you will have to continue the code review for PR/PM/PW layers as you currently do.

26. We currently have Developers using local databases (Oracle XE) and experiencing a number of issues:

  1. With the sse_data.dbf file for the local database replaced with OracleXE database, it is a NOT a pleasant experience to figure out how to setup the local DB for developer and took 4.5 days to figure out the issue for a season Siebel admin.  And it takes roughly 3/4 of the day for a new developer to be setup.
  2. With Oracle XE database, a developer cannot have two local databases on the same machine without going through gymnastics.
  3. The LocalDBsetup.exe program suggested in bookshelf is missing few critical flags
  4. Size of temporary tablespace varies significantly if you install Siebel WebClient first OR Siebel Tools.  If Web Client is installed first, then initialization of Siebel local database fails as temporary tablespace is 2GB;
  5. The size of local database increase tremendously from 2 – 4 GB (see_data.dbf) to 30GB (OracleXE);  If a customer refreshes dev with Prod to have more data available for unit testing then I cannot imagine the size of the local database.
  6. Once cannot have customized positions for developers as the local db initialization fails and the only recourse available is to grant everybody Siebel Admin responsibility and position (seriously, no Siebel admin will agree for this setup and testing custom responsibility / views locally is a serious issue)
  7. Local database has to be extracted with Repository for Tools to work on local database and this bloats the server side Siebel directory size

Your pain should be resolved somewhat in IP17 as there will be no developer database option.

There is no local database for IP17, except for standard remote DBs for Siebel Remote usage.

There is no local database for Tools in IP17

27. Please outline Web Tools vs. Composer. Are they the same tool?

No. WebTools is part of the overall Composer offering.

...does Composer require new licenses?

No. Composer is free as part of a Siebel Tools license.

28. Is there still a local developer database needed?

No, local database is no longer needed

29. What is Siebel Tools still required for in IP2017?

Composer does not include Workflow designer, Task UI editor or drag and drop composition of applets.Schema, Dock objects, EIM mapping, scripts, and any wizards are still part of Siebel Tools and will be transitioned to Composer in the near future. 

...if Siebel Tools co-exists then will that require separate database?

No, they work against the same database and same Workspaces. Siebel Tools and Web Tools are both windows into the Workspaces.

...So, to understand correctly with IP2017 we need Siebel Tools for doing some advance customization that cannot be done in Web Tools. Will this Siebel Tools need to be installed on local machines and have local database extracted to work upon?

No, local database is not needed, you need Tools on local machines connected to the development database that is centrally hosted.

...with this model, whats is the flexibility or option we are loosing with not having Siebel local database?

not really losing anything - gaining a lot of flexibility - losing the option to work fully disconnected (potential issue if the database was across the other side of the world).

...How about Apply / Activate for new tables or columns?

Same as before, but it is not Workspace enabled, so will apply to all branches and across repository.

30. With IP2017, we will still have the option to continue to use Siebel Tools and local database based development approach right?


31. When upgrading from let's say IP14, will Composer be automatically configured on the IP17 environment ?

When upgrading to IP2017, Workspaces will be created by default and Composer will be automatically enabled.

32. Manifest is used to propagate to higher environments with the repository until now. Will it be taken care by Workspaces for a code push to higher environments going forward?

Manifest will still be propagated along with repository.

33. When are all the web templates moved to Web Tools?

Web templates will be migrated to the database during IP17 installation.

34. How are deletes handled by Workspaces?  For instance we have many empty or deprecated Browser Script records. Can we delete them and publish the Workspace?

You cannot really delete, you can only inactivate.. this is to support versioning.

35. Can multiple developers lock the same object (common object) for editing and how are the changes merged with the final copy of object ? will we still have option to work on objects locally? if we want to discard after making changes?

Workspaces do not require locking of objects, you don't 'lock' objects anymore - Workspace permits multiple developers to work on the same objects. There is no local database anymore. 

35. Will we have to significantly increase database tablespace sizes to accommodate Workspaces? is there a limit on the number of Workspaces?

Increase in tablespace size will be around usage of CLOB data type for the most part. There is no limit on the number of Workspaces or Developers.

36. Since there's no srf, will the dedicated client run on the same database / workspace as Tools or Composer ?


37. Is there any syntax check for Web Template changes?

The Web Template syntax has moved to a new syntax - called ODH, which is well formed html. It moves info that used to be in tags into attributes inside html. 

38. Are Workspaces related to a user ? will it still be possible to test on dedicated client with another user having another position/responsibility ?

A user owns the Workspace - anyone can view it, but the user can only edit it

...Can a developer get to know if someone else is also working on the same object?

Yes, they can view other's Workspaces

...So multiple projects running at the same time will see any changes to objects not currently included in Web Tools? is that correct?

Not true, depends on how you have set up Workspaces (integration) and how you are running your projects. 

39. After submit, can we make changes to the same Workspace if needed?

No changes in the Workspace after submitting. 

40. The Workspace icon on application, can it be disabled?

No it can not be disabled, it only appears if you have the appropriate responsibility. 

41. How to ensure that the changes of one branch are propagated to other branch so other branch develops on top of prior branch? 

You can merge the branch to the other branch before development, it is based on the strategy you follow with branching for Workspaces. You can deliver to main Workspace and then rebase to the integration Workspace where you need those changes.

42. Scenario: If a single implementation has multiple development tracks involving common objects to be changed for each of the track and frequent deployment to a production environment with the intent to make sure all the parallel projects work on top of the last modified common object. How to achieve this ? do we have to merge branches prior to starting the other track?

Yes, but requires careful thought about branching strategy and merge/rebase strategy.

...If I have 10 changes and one is conflicting will I need to rebase ? and my other 9 changes would be submitted?

Yes, you need to rebase

...Does the Rebase pull down updates from the nearest Integration Branch or from Main?

Rebase is from the latest version of the integration branch if your developer workspace is off that integration branch.. it will be main if the developer workspace is off the main.

43. Object tagging concept is gone?


44. For Integration Object deployment is it required to publish to runtime database?

Yes, anything you would have compiled to an SRF now needs to be published to the runtime database.

This facility of “Deploy to Runtime” was added exclusively to IOs (before we had Runtime tables for whole repository) in order to avoid server restart; as compile to SRF (of the IOs created due to web service/wsdl import) required server restart.  Now that we have the IOs published to Runtime tables (Instead of SRF) so no need to deploy IOs to database.  
But the advantage of “Deploy to runtime” option in tools is that you need NOT deliver/publish the workspace but still use the deployed IOs, so the view and associated mechanism is intact user can either choose to say “Deploy to runtime DB” or deliver/publish the workspace before using the IOs.

45. If everything is managed through Workspaces then how will a configuration review of the implementation be performed, or how can we share our repository?

Workspaces can be exported to SIF, and the database can be flattened for those purposes. Scripts are also possible to export seed data. Oracle ACS have already updated their services to accommodate the new release.

46. Regarding Web Templates are <od> tags proprietary or some standard?

They're just tag attributes - they are proprietary but the pattern is like other systems like angular.

47. How are server script conflicts in the case of parallel development going to be resolved?

True conflict resolution is not there since scripts are stored in a clob data type so they need to be copied over to a file and require a file compare process to ensure the merge contains the combined script.

48. Are there plans to "unversion" the currently versioned objects (workflows, tasks, products, signals etc.). Because Workspace versioning of versioned objects might create problems for branching and merging.

Products and signals are not repository artifacts, so versioning is different than Workspace versioning.

49. Is it hard to rollback the delivery? Is there a rollback available in deployed project didn’t meet expectation ?

You can quickly revert to a previous version of a Workspace. There isn’t complete 100% rollback yet though, as PR/PM/PW/CSS layers still sit outside of workspaces, meaning that the file system would have to be rolled back separately. Moving these layers to Workspaces is on the roadmap, at which point they will be fully versioned and enjoy rollback-ability too.

50. Scenario: What if more than one people work on the same object, one of them needs to deploy it first? For work on same object we had Lock/Unlock and it seems remains same.

Let's say one person deploys, the second person will be given a warning for any conflicts during the Publish step, and given the option to rebase their configuration against the current repo, much more advanced than lock/unlock. Once you open a Workspace, you can configure everything, not just a single object/project

Q. Rebase? Like in git?

Yes like GIT.

51. How will the conflicts be resolved in case of multiple branches?

Incremental Repository Merge (IRM) features are employed to enable the developer to resolve conflicts.

52. After Workspace are changes delivered, will the version revert option will still be enabled? or it is only until you deliver changes?

Once a Workspace is delivered it is Read Only.  No further operations are allowed

53. Will Composer support the multilingual application too?

Yes, it will support Multilingual Applications

54. Workflow Policies – How do you edit the Workflow triggered by the Workflow Policy if the Workflow Policy is not part of a Workspace? At least the Workspace from which Workflow Policy should be stored in S_ESCL_REQ. So it could be executed within the context of the same Workspace?.

Workflows have 2 components – Design Time using Siebel Tools and Run Time using Applications. Design time using Siebel Tools is Workspace enabled. Once the changes are done, you publish and activate the Workflow. So at any given point only one Active version of the Workflow is available for Runtime (SiteMap->Application Administration -> Repository Workflow Processes to Activate). Workflow Policy is not Workspace enabled. Workflow Policy interacts with the Runtime version of the Workflow and hence always triggers the current Active version of the Workflow.    

55. When you have a lot of Workspaces, is there a way to filter/prune the old ones?

Not as of now. in general, from time to time, it makes sense to flatten - no pruning options (as yet)

56. Workflows and Task objects currently have incremented version numbers. In a versioned Workspace instance this concept will lead to confusion. If two developers create a new record with the same incremented version (e.g., Version 2) and now the second developer performs a ‘Submit for Delivery’ that results in conflicts on the same WF Name/WF Version that will not be easily addressed in an IRM-style conflict resolution.

For Workflows, Workspace versioning supersedes the older versioning of Workflows. Tasks are not Workspace-enabled yet, so no change.

57. Does Web Tools trigger DMLs in the same production database?

Web Tools will fire DMLs to the database it is connected too, similar to Siebel Tools. Web Tools works within Workspaces and any edits done to DR definitions is applied to the database it is connected. The recommendation is to run Web Tools only on development databases. 

58. Does ‘sadmin’ or an administrator user have the ability to submit changes of a Workspace made by any developer? In the case that the account is locked/or a developer is not available?

No, Administrators cannot modify or submit for delivery. Submit for delivery can be done only the developer and when the Workspace is in ‘checked-in’ status. If required, an Admin can export the contents of a developer’s Workspace and import into a newly created Workspace and deliver from there.

59. If we are developing with 16.0 and 17.0 on two different environments, what is the recommended strategy to combine both changes at a later date?

There would be a couple of options in this scenario:

  • If changes are minimal and contained, extract an archive (.sif) file using Siebel Tools from your IP16 environment. Create a new developer Workspace in your IP17 environment (under the appropriate branch). Import your archive into the Workspace. Do any required rebase if there are conflicts and deliver your changes.
  • If there are too many changes, do a development upgrade of your IP16 repository to IP17. Setup a Migration plan with the Source as your IP16 (upgraded to IP17) environment and the target as your IP17 environment. Create a new integration branch on your target and perform a full DR migration. Once complete, you can merge your new integration branch to MAIN and resolve any conflicts.

60. In a multiple release scenario (integration branches) where both releases e.g. Summer and Fall, will contain considerable configuration changes, there will be a large number of conflicts, meaning governance will take an even longer time (and may require developers to edit their code again). What’s the best strategy for this scenario?

  • Developer Workspace branches are created and delivered within each integration branch and all governance is for deliveries within those integration branches and not across integration branches.  In this case, developers working under e.g. a Spring Release integration branch will create Workspaces under this integration branch, make necessary changes and deliver these changes to the Spring Release integration branch only.  Any governance that is applied is for deliveries to the Spring Release integration branch only. A similar approach is followed for e.g. a Fall Release integration branch.
  • Once a release is done, you would then deliver the integration branch to your Main branch and then Rebase your other integration branches from Main.  
  • In this case once your Spring Release is done, then Deliver the Spring Release integration branch changes to MAIN (resolving any conflicts via Rebase/Conflict Resolution). Once complete, perform a Rebase of your MAIN branch which now has changes from the Spring Release to your Fall Release integration branch and resolve any conflicts so that the Fall Release integration branch has all the latest changes from the Spring Release.
  • Developers under the Fall Release integration branches will then Rebase the new changes into their developer Workspace branches prior to testing and delivery.
  • The key to getting this right is to have the right strategy of Workspace branches that works for your development process and deliver accordingly. 

61. How to push the changes from one Workspace to another?

Archive (.sif) out changes from one Workspace and import it into another Workspace and resolve any conflicts.

62. How to connect a Workspace to a completely different database (assuming different databases for Development, Test and Production)How to connect a Workspace to a completely different database (assuming different databases for Development, Test and Production)

  • Workspaces are created for a specific Database (e.g. Development database). You cannot re-connect a Workspace to another database
  • If you want to preview your changes (unit test) then login to an application that is connected to the same Development database where you created the Workspace and select Open. Open that Workspace via the Workspace dashboard, then perform an Inspect to unit test your changes
  • If you want to test or preview your Workspace changes on another database (say Test or Production), then commit your Workspace changes in your Development database and use the Application Migration tool to migrate these changes to your Test environment for testing and once changes are fully tested, you would then migrate these changes using the Migration Application to your production database.

63. Do Workspaces only apply to Object Manager (OM) components?  for example, can other components such as Workflow Process Manager or Loyalty Realtime Engine point to a specified Workspace, or do they only refer to "MAIN"?

Workflow Process Manager is also an OM based component. Workspaces apply to any component that references metadata.

64. Do we still need a local database after upgrading to 17.0? or will be completely migrated to Workspaces?

You do not need a local database after 17.0 for development, it will be Workspace only

...for this purpose remote users will have to download a local repository? can you develop on how will it work ?

Remote users use local database for two scenarios: 1) for using the Mobile Web Client and 2) for local configuration using Siebel Tools. The recommendation is to move the development to a central database using Workspaces. For scenarios where there is no possibility, you can use a local database but you will have to archive (.sif) changes to the Workspace on the central development repository.

65. With IP17, will it be possible to have remote users?

Yes, if you are referring to remote users from the perspective of a disconnected client.

66. Is there a sample database/environment for IP2017?

There is a sample database for IP2017 which is also Workspace enabled.

67. How will the Table apply/activate process or Workflow development/migration happen? what about ddlsynch?

Tables are not workspace enabled, so it works the same way as before. Workflows (Design time) is Workspace enabled, but runtime Workflows are not Workspace enabled.

...when you say that the Table process will work same way, does that mean we still need local database to alter the Table schema? contradictory to "only Workspaces" concept?

...if the sample database is Oracle 11g XE based, it can be bought to the server database if the DBMS is Oracle.

68. For branching & merging with IP2017 - does this also work for Tasks and Workflows (visual programming) and scripts? can the merging of branches and creating new integration Workspaces be automated?

Delivery of integration Workspaces and delivery of developer Workspaces to integration Workspaces can be automated.

69. Is the applet layout editor in Tools or Web Tools in IP17?

Applet layout editor is in Web Tools as well in read only mode. In Siebel Tools, it is interactive with drag and drop.

70. How is it possible to develop scripts in Web Tools?

Editing script and script validation is not supported yet by Web Tools; you still need to use Tools to do this.

71. Is Siebel Object Tagging available? (for example, if two developer work on the same object/same field and merge those changes in a different release time in central repository)

Object tagging is not available with Workspaces. With Workspaces, you do not need object tagging as Workspaces support versioning and is meant to provide a more cleaner way for version control, rebase and merging.

72. Scenario: multiple developers working on the same object adding different functions in Server Script – how is this handled?

For server script, it is an attribute, so when multiple developers add different functions, it will show up as conflict and conflicts will need to be resolved by developers.

73. Are Products on the roadmap to become part of the Workspace concept including branching & merging?

This is under consideration but not available in IP2017.

74. Is there a material increase in database space needed in higher environments, or just for Development?

It is primarily for development databases only.

75. What is the relationship with non-OM components and their Workspaces? 

All OM-based components including Workflow Process Manager (WFPM) are Workspace enabled. You have to set the Component parameter (WorkspaceBranchName) to the same branch (MAIN or Integration branch) for both WFPM and the OM that made the same request.  Component parameter can be set via Sitemap > Administration Server Configuration > Servers > Components > Parameters (Hidden)

Only OM based components are Workspace enabled. Non-OM based components typically delegate requests to OM-based component for any operations involving Siebel metadata/data.

76. When a Workspace is open for editing is it indicated somewhere in Web Tools prominently like on the Menu or Toolbar the exact name of the Workspace that is currently being worked upon?

In Web Tools, it is not there currently. You can see what workspace you are working on by going to Help Menu. We have added this request to our backlog and will implement this soon. Alternately you can go to Workspace dashboard and see which workspace you have opened for editing.

Join the discussion

Comments ( 8 )
  • Jason M Monday, June 12, 2017
    Question 44 is a good one in that there currently exists the concept of Runtime tables for Integration Objects for IP2016 and earlier releases. (These are under WebService Administration Screen, Deployed Integration Objects view.) Since the SRF is moving to runtime tables overall, we need to know if this view is now deprecated or if publishing to main IW branch will push IO records to the same table.
  • Jason M Monday, June 12, 2017
    Could you elaborate more on your answer to Question 48 to address workflows and tasks? Workflows and Task objects currently have incremented version numbers. In a versioned Workspace instance this concept will lead to confusion. The way I see it working is that two developers create a new record with the same incremented Version (e.g., Version 2) and now Submitting for Delivery by the second developer results in conflicts on the same WF Name/WF Version that will not be easily addressed in an IRM-style conflict resolution.
  • Jason M Monday, June 12, 2017
    Could you explain a bit more about non-OM components and their relationship with Workspaces?

    For example, we have triggers in the OM that make requests to the Workflow Process Manager component to run a workflow asynchronously. The actual Workflow being executed in this component, even if it is unchanged among releases, calls a custom Business Service that has been modified with a new script function for an upcoming release. That modification is deployed to the IW branch for the OM under test.

    In this situation, will the WFPM component know to reference the same Integration Workspace as the OM that made the request? Or will it only reference object versions deployed to MAIN?

    Similarly, how would we control workspaces for inbound, task-based server components such as MQ or JMS receivers?

    I assume that only OM-based components are Workspace enabled, which will reduce complexity but limits our ability to use a single environment for multiple development releases. Please confirm so we may plan accordingly.

  • Rao Tuesday, June 20, 2017
    When a workspace is open for editing does it indicate somewhere in webtools prominently like on the Menu or toolbar name of the workspace that is being worked upon?

  • John Tuesday, August 22, 2017
    Jason/Rao, we've added these questions into the FAQ - thx!
  • JV Friday, December 8, 2017
    Regarding #62, how does a developer unit test after configuration is done in particular a workspace without delivering to main workspace. What client - thick or thin?

    Thank your clarifying.
  • Vishal Friday, February 23, 2018
    Please provide more details around dedicated client. If there is no concept of SRF and if dedicated client is on same DB/repository as Tools how do I test custom changes without impacting others.
  • John Tuesday, April 17, 2018

    Hi - IP 2017 is pretty much a revolution in terms of Siebel CRM agile development. I would strongly recommend you watch the Webcast Series presented on Siebel Composer.


    In a nutshell the following steps are how you review a change:

    1. Open Web Tools (part of Siebel Composer)
    2. Open a Workspace
    3. Make changes
    4. Open application i.e. Call Center
    5. Open the Workspace where you made the changes
    6. Click Inspect
    7. Test changes (Test Automation)

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.