Details on Web Service Definitions, RunTime Messages, and Custom Object Visibility
Introduction
Application Composer is the main toolkit for customizing and extending Oracle Sales Cloud. By providing a varied collection of user-friendly customization tasks from a consolidated browser-based entry point, Application Composer opens up a safe and productive tailoring environment for developers and non-developers alike.
Most users who have had some hands-on experience with Application Composer know about the need to choose appropriate application containers before selecting and working with the Sales Cloud components targeted for an extensibility project. For example, the Common application container allows access to common components used across other application containers: Account, Address, Contact, Household, Resource, and Task, among others. The Customer Center application container allows access to components specific to customer-related objects in Sales Cloud: Activity, Asset, Sales Account, and several child objects belonging to these top-level objects. Likewise, the Marketing application opens up access to marketing and some sales activities related to marketing; the Sales application opens up access to Opportunities, Partners, Forecasts, and several other sales-related objects; the Sales Catalog application is a container for Product Group components; and finally, the Territories and Quotas application allows access to Sales Goals and Sales Territories objects.
On the surface this seems to be a straightforward and reasonably intuitive arrangement: select the appropriate application container for whatever objects and/or tasks need to be extended or customized, do the work on the requisite components, and repeat as necessary depending on the scope of the overall project. Hidden beneath the surface, however, are several potential pitfalls with certain App Composer customization tasks that may impede development progress without prior knowledge about how some of these tasks behave at runtime when application container context changes.
- Trap #1: Web Services definitions and their visibility (or more accurately lack of visibility) from one application container to another.
- Trap #2: Using the RunTime Messages customization task as a debugging aid for Groovy scripts, and how that tool needs to be configured across application containers for it to work to its full extent.
- Trap #3: Limitations with the behavior and visibility of custom objects across application containers.
Knowing about these module-specific and object-specific behaviors, and being able to work around them efficiently, will lead to less time spent sorting out extraneous issues, freeing up more time to address the real business problems. This post explains these behaviors hidden under the surface and provides alternatives on how to work through using web service definitions across containers, how to configure RunTime Messages debugging across containers, and how to plan custom object implementations to avoid usage limitations across application containers. Both Release 8 and Release 9 specifics are covered, as there are significant differences between the two.
More on Application Containers
Application Composer’s top-level application container organization inherits from the applications assigned to the managed servers in the CRMDomain Weblogic domain of the Sales Cloud pillar application. The relationship between the application containers exposed in Application Composer, their corresponding managed servers, applications, and corresponding URL context roots is summarized here:
| Application Container | Managed Server | Application | URL Context Root |
| Common | CRMCommonServer | CRMCommonApp | /crmCommon |
| Customer Center | CustomerServer | CustomerApp | /customer |
| Marketing | MarketingServer | MarketingApp | /marketing |
| Sales | SalesServer | SalesApp | /sales |
| Sales Catalog | OrderCaptureServer | OrderCaptureApp | /orderCapture |
| Territories and Quotas | CRMPerformanceServer | CRMPerformanceApp | /crmPerformance |
| n/a | ContractManagementServer | ContractManagementApp | /contractManagement |
In the CRMDomain, with only a few minor exceptions there is a 1:1 relationship of application to managed server, as well as a 1:1 relationship of web module context root to deployed application. Among other things, this set of relationships makes it possible at runtime to determine the active application container context from the displayed URL in the browser. Knowing about these relationships is a powerful debugging aid on its own merit.
Implications for Web Services
To call SOAP web services in Groovy scripts, they first need to be configured in Application Composer’s “Web Services” customization task. After these service definitions are created, they become referenceable objects from within the Groovy script editor. Moreover, request syntaxes and other details about using the service are pulled from the service’s WSDL files and made visible in the Groovy editor palette under the Services tab. The ability to see details of the SOAP web service definitions from within the Groovy scripting editor, and then to take the next step of importing correctly-formatted web service request calls into scripts, are huge productivity boosters.
Being able to validate scripts before saving them in the editor is another major script-writing aid. Unfortunately, validation is only a partial guarantee that scripts will run as intended in different application container contexts. An example will help make this point more clear. For discussion purposes, assume that a web service had been defined in the Sales application container and that it is being called from an Action button placed on both the classic UI and simplified UI Opportunity details pages. (The Opportunity object is accessible from the Sales application container.) Unit testing of the script in each UI uncovers a strange anomaly: the script runs perfectly in the classic UI, but in the simplified UI the script throws a NullPointerException as the web service is getting invoked.
What could the cause be? Maybe comparing the different runtime URL’s for classic and simplified UI’s will offer a clue.
Here is the classic UI URL for the Opportunity details page:
And here is the URL for the same page in the simplified UI:
From the URL’s, it is obvious that the simplified UI page runs in the context of the CustomerCenter application container instead of the Sales application container. As it turns out, what causes the NullPointerException is that in Release 8 the CustomerCenter application has no visibility into the web service definition that exists in the Sales application container.
Correcting this visibility issue is relatively easy: create an identical web service definition in the CustomerCenter application container and the NullPointerException will be resolved. The workaround – creating multiple copies of the web service definition — is required for Sales Cloud Release 8 to avoid NullPointerExceptions. With Release 9, fortunately, these duplicate web service definitions are no longer required as single web service definitions are visible across all application containers, no matter where they are defined initially.
Implications for RunTime Messages
Runtime application container contexts also have an effect on the behavior of RunTime Messages, the Application Composer customization task that aids in Groovy script debugging. Currently, println statements added to Groovy scripts are selectively picked up by the RunTime Messages console, but only if the collection of runtime messages is enabled for the customization task.
RunTime Messages Enabled for matt.hooper in the Sales Application Container:
RunTime Messages will not be collected for matt.hooper in the Customer Center Application Container:
What can be somewhat confusing is that the scope of the enabled setting is limited to a logged-in user in the active application container. An example will help clarify this behavior. Again, for discussion purposes, assume that an Action button that runs a Groovy script (embedded with appropriate println statements for debugging) has been placed on both the classic UI and simplified UI Opportunity details pages, and additionally, runtime message collection has been enabled in the Sales application container for the logged-in user. When testing the behavior of the Action button in the classic UI, runtime messages are collected and are visible in the RunTime Messages console for the Sales application container, but when testing the button in the simplified UI, messages are not visible. The solution is to also enable the collection of runtime messages in the Customer Center application container for the logged-in user, continue testing, and access the debugging content from the RunTime Messages console in the Customer Center application container instead of the Sales application container.
This RunTime Messages behavior is identical in both Release 8 and Release 9 of Sales Cloud, but it may change in future releases.
Implications for Cross-Container Visibility of Custom Objects
In recent releases of Sales Cloud, considerable development work has been devoted to improve the visibility of custom objects across application container boundaries. Due to a few complicated dependencies, however, total visibility could not be extended to custom objects created in the Common application container for Release 7. Therefore, in Release 7 and Release 8, (1) custom objects created in the Common application container are not totally visible from other containers, and (2) non-Common-Container custom objects cannot be referenced from the Common container. Release 9 enhancements have greatly improved cross-application-container visibility of objects, notably for the Common application container.
Here again a couple of examples should clarify what exists in Release 8 and what has been improved in Release 9. Assume for sake of discussion that a custom object for location lookups called Location has been created in the Common container. The plan is to use the Location object as the basis for dynamic choice lists (DCL’s) in other application containers.
Unfortunately in Release 8 that dream will remain unfulfilled due to the custom object visibility limitation:
Note that in Release 8 custom objects belonging to all containers with the exception of those created in the Common application container are visible and selectable for Dynamic Choice Lists.
In Sales Cloud Release 9, however, the default behavior is that these specific limitations with the Common container have been removed. All Common container custom objects are now visible in other application containers:
Knowing about these behaviors prior to creating custom objects should minimize the need for object design rework at later stages of the project. In Release 8, although object visibility is much improved from earlier versions, there are still some limitations. In Release 9, visibility of custom objects has been improved even more; custom objects defined in the Common application container are usable in non-Common applications.
Summary
Without knowing about certain release-specific behaviors of Application Composer customization tasks and objects, it is possible that developers will have to spend additional time debugging NullPointerException’s with the use of web services in Release 8. Moreover, even the act of debugging these issues may become more of an effort than it needs to be, because enabling RunTime Messages is scoped to single application containers and one user identity. Not knowing about this behavior may lead to more frustrating debugging of extraneous issues when the application container context changes at runtime.
The application container structure in Sales Cloud Application Composer is tied to the back-end makeup of the Weblogic CRMDomain. Several App Composer design-time objects require special attention as the results of their built-in behaviors may not be easily traceable to the root cause. In Sales Cloud Release 8 web services definitions are not visible across application container boundaries, so objects that run in a different application container from the container in which they are visible at design-time (i.e. almost anything that runs in the simplified UI) will have issues if scripts try to access web service definitions. Fortunately the need to define duplicate web service definitions has been rectified in Release 9. RunTime Messages are another component requiring special attention when debugging scripts which run from components added to the simplified UI. Finally, knowing about custom object visibility behaviors to and from the Common application container can be a boon during the design phase of extensibility projects.
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission