About Inspecting Objects in Workspaces

Integration Workspaces (including MAIN, which is a special example of an IWS) contain a compiled version of each object modified in that Workspace.

• MAIN contains a compiled version of every object.

• Each IWS contains a compiled version of each object modified and delivered from any child Workspace beneath it.

The compiled versions of the objects are stored in "S_RR*" tables. For example, compiled Applet definitions are stored in S_RR_APPLET. At runtime, the Application Object Manager reads the definitions of the objects from these tables.

Developer Workspaces, however, do not contain compiled versions of each object. Rather, they contain any changes to the raw repository definitions. To test these changes before delivering them to a parent Workspace, select the Inspect option from the Workspace Dashboard. This option will compile any changed objects in memory as they are needed, rather than read from the Runtime Repository table definitions.

Note: Do not attempt to inspect the Developer Workspace created by the RepositoryUpgrade utility. This Workspace could contain thousands of modified objects and the inspect action will attempt to compile and load all these object definitions into memory. This can be an enormous task and could result in an out of memory error, slow performance, or incorrect object behavior as resources become constrained on the development machine on which inspect is operating. Instead of inspecting the Developer Workspace, consider delivering the Developer Workspace created by the RepositoryUpgrade utility to its parent Integration Workspace which is also created by the RepositoryUpgrade utility. The delivery process will compile the changed objects at the time of delivery. Then, open your end user application such as Call Center and open the Integration Workspace to see how the Oracle-delivered configuration behaves in your environment.