How To Find Application Data For Use In Customization & Integration
By Richard Bingham-Oracle on Apr 03, 2014
Sometimes you need internal values in order to build and test out your customization, extension, or integration. Examples might be using the PartyId that represents a person or business unit, or the primary key of a transaction number against which your extension code applies. Often these unique values are not shown on the user interface, and in a managed environment (e.g. Oracle Cloud) you may not have direct access to SQL tools to interrogate the tables. There are, however, are a couple of alternative methods that you can use.
Add A Custom Field
If you are an Oracle Sales Cloud user then you can add a custom field to your standard object. When creating the field you can set it's Default Value using an Expression, and in the Expression Builder Palette the fields tab gives the entire contents of the underlying view object(s), making it a great source for internal fields like primary keys and flags. The example below shows the PartyId field for a person, used as a customer contact.
Once added to a page you can see this in the UI for each record. Obviously this is not the most elegant solution, since only shows single values at a time, and you are adding intentionally hidden fields onto the UI, however it may be the fastest/easiest during ad-hoc development and system testing.
Use Web Services
The OER system catalogs all the web services available, most of which have a getXXX or findXXX type operation for returning data. The response Service Data Objects (SDO's) are again based on the underlying View Objects and as such include more fields than are exposed on the standard user interface.
Also once you've got a reusable payload it's pretty easy to do, such as the example below querying Opportunities using SOAP UI. As you can see the response is extensive and includes many internal data values (bright yellow).
As you may notice, some web service requests themselves need internal ID values (like optyId above) and so this method might not always help. Read on for alternatives.
Another tip here is that when looking at the SDO data returned it can also help you when writing custom groovy against your objects, since the huge number of (sometimes similar) field names are not always easy to understand, so having the actual data shown alongside them can help you make sure you are using the right one!
Use BI Analytics
The massive amount of seeded BI Subject Areas in Fusion Applications often also contain key (join) fields that are otherwise hidden. These subject areas are intuitively named, and it takes little time to drill into the related area to check what fields are available. As per the screenshot below, choosing the Reports and Analytics sidebar, from the menu pick New - Analysis, and selecting the subject area 'Sales - CRM Opportunities and Products Real Time', it exposes dozens of fields, including the Opportunity ID. Simply adding sorting and filtering using the BI Composer wizard allows you to include a criteria. Finally the handy preview checkbox even shows the results right away, eliminating the need to even save the analysis.