| Oracle® Fusion Applications Developer's Guide 11g Release 7 (11.1.7) Part Number E15524-08 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Developer's Guide 11g Release 7 (11.1.7) Part Number E15524-08 |
|
|
PDF · Mobi · ePub |
This appendix describes the theory of the Oracle Fusion application taxonomy, how to view the taxonomy, and how to extract taxonomy data from a table and how to insert taxonomy data into a table.
This appendix describes:
The theory of the application taxonomy
How to view the taxonomy
How to extract taxonomy data from a table and how to insert taxonomy data into a table
This appendix includes the following sections:
Section A.1, "Introduction to the Oracle Fusion Application Taxonomy"
Section A.2, "Working with Objects and Methods in the Application Taxonomy"
It is important to note that there is no tool for working with the taxonomy; developers use public business objects and do all work within JDeveloper. In general, only developers who are referring to modules, such as Application, will need to work with the taxonomy.
The Oracle Fusion application taxonomy organizes the artifacts and functions of Oracle Fusion Applications into a hierarchical structure. Every Oracle Fusion development artifact or file is tagged. The structure starts with the Application Line and extends through the Logical Business Area.
Application Line
Application Family
Application
Logical Business Area
Logical Business Area
In the taxonomy user interface, the hierarchy would appear similar to the example shown in Figure A-1:
The taxonomy hierarchy provides a map of the dependencies that exist within an application and across applications.
Seed Data
The Oracle Fusion Applications Design Repository (ADR) team has provided Taxonomy seed data for the following levels in the hierarchy: Application Line, Family, Application, and Logical Business Area (LBA).
You can create as fine-grained an application taxonomy as you wish. You can break up an application into sub-applications or pseudo applications. For example, there are many setup use cases where an overall process is made up of many smaller subordinate processes.
The applications taxonomy is especially useful in managing various phases of the application lifecycle. These phases include:
Installation and Deployment
Patch Creation
System Administration
Diagnostics and Maintenance
Patches and patch sets can be constructed based on the data defined in the taxonomy. You can choose any node of the taxonomy as the source for a patch file manifest. That starting node can scale all the way up to the top of the application taxonomy tree for a new release for the entire suite.
System administrators monitoring performance, processes, system use, and so on, can use the application taxonomy to organize information and navigate to the level of detail they require. Administrator dashboards will start at higher levels of the taxonomy to provide broad overview of system status. When trouble is detected, the taxonomy can be used to drill down to where attention is required.
Patches will be tagged with the versions they contain. When a patch is applied, dependency information in the taxonomy can be used to determine which parts of the system will be affected. This can be used to assess system testing requirements after the patch is applied, or to schedule partial downtimes while patching is in progress.
Diagnostic tests, logging, error messages, online help, support bulletins, and other artifacts are tagged with the module and version in the taxonomy to which they pertain. When trouble is detected, information from the customer's system can be matched with these tags to direct them to appropriate assistance.
If the problem cannot be resolved through diagnostics and help, the taxonomy can be used to search for patches available for a particular module and version. Patches could be available at any level of the hierarchy, from one-offs, through larger roll-ups. The taxonomy can be used to follow the troublesome module up through the hierarchy to search for larger roll-ups that might be relevant.
If support is required, the taxonomy can be used to automatically construct Support Information Bundles, containing version information, with the results of diagnostics registered for these components.
The organization of the application taxonomy does not need to match the physical file directory structure, which is unlikely to consistently correspond to the functionality provided by those files. File directory structures often serve to group files according to a high level file type (such as all seed data files in one directory, all Java files in another directory, and so on), rather than by their functionality.
The applications' Java EE package structure is a simple physical hierarchy based on the directory structure into which you organize your runtime files on disk. It is identical to the package structure that you use when defining Java class file packages. The concept has been expanded to also support metadata files, such as JSPX files. However, the information maintained by the application taxonomy supports many functional capabilities that cannot be supported by the standard Java EE package hierarchy.
Many of the artifacts that comprise a given application are shared among various applications and modules. The relationships among applications and artifacts constitute a network rather than a simple hierarchy, and are essential when interrogating and modeling dependencies. There is no support for such an integrated map of relationships in Java EE package structures.
There are other critical business requirements that cannot be satisfied by using a physical directory structure to organize an application hierarchy. Customers will often extend or subclass various runtime components to customize the application behavior to meet their specific business needs. Over time, application teams will wish to refine or refactor their application hierarchies as they add more features and functionality. Teams will want to refine or reorganize modules that leverage various artifacts. The application taxonomy's logical definition of applications and their related runtime components saves customers from having to modify their references to these packages if the logical hierarchy is changed.
In the application taxonomy, the delivery hierarchy is the master source for all the directories and files that comprise an application.
The delivery hierarchy represents the relationships between files and the application team that is responsible for the development, maintenance, and delivery of those files. Nodes within the delivery hierarchy have unique parents, so there is one path through the delivery hierarchy to any given file.
Every application registers task flows with the Functional Setup Manager that provides a single, unified user interface that allows customers and implementers to configure all Oracle applications by defining custom configuration templates or tasks based on their business needs.
The Functional Setup Manager UI enables customers and implementers to select the business processes or applications that they want to implement. For example, a Human Resources application can register setup activities like "Create Employees" and "Manage Employee Tree Structure" with the Functional Setup Manager. Trees task flows then provide the mechanism for an application team to register an activity such as "Manage Employee Tree Structure," which in this case, is a tree structure task flow with the tree structure code parameter set to some HR tree structure. Table A-1 lists the task flow and its parameters.
Table A-1 Taxonomy Task Flow and Parameters
| Task Flow Name | Task Flow XML | Patterns Passed | Behavior | Comments |
|---|---|---|---|---|
|
Manage Taxonomy Hierarchy |
|
[pageTitle] |
The Manage Taxonomy Hierarchy accepts the optional parameter [pageTitle] and navigates to the Taxonomy Delivery Hierarchy page. |
This page serves as the starting point from which a user can select a particular node and perform the available actions, such as create, update, and view components for a selected node. From this page, a user can navigate to other task flows, such as Search Hierarchy, View Components and Search Components. |
You can use the application taxonomy at a lower level by using the public entity objects and view objects.
For example, you can create an association between the application team entity object, which has a foreign key reference to alternative_id in ApplTaxonomyPEO, and provided service methods to either join to the taxonomy table or to traverse through the taxonomy hierarchy using an API (for instance, to which Family does a given Application belong?) or for other lookup information about the nodes (for instance, what is the short name for a given application?).
These items are applicable to some Oracle Fusion Middleware Extensions for Applications (Applications Core) tables.
Who Columns
All tables containing seeded or transaction data must include the Who columns shown in Table A-2:
Table A-2 Who Columns
| Column Name | Type | Null? |
|---|---|---|
|
|
|
Not Null |
|
|
|
Not Null |
|
|
|
Not Null |
|
|
|
Not Null |
|
|
|
If the table has "extended Who" columns used to track updates by Oracle Enterprise Scheduler Service programs, the columns must be changed to those shown in Table A-3. You do not need to add extended Who columns if the table does not already have them.
Table A-3 Extended Who Columns
| Column Name | Type | Null? |
|---|---|---|
|
|
|
NULL |
|
|
|
NULL |
|
|
|
NULL |
Replace RAW Columns with VARCHAR2
Raw columns may only be used in internal tables that are never directly exposed in Oracle Application Development Framework (Oracle ADF).
Columns containing user GUIDs should be changed to varchar(64).
Columns containing all other GUIDs should be varchar2(32), and use rawtohex() to convert the raw GUID to a hex value.
Raw columns containing anything else should be replaced with Binary Large Object (BLOB).
The ApplicationLine column of the Taxonomy table has been denormalized to allow data for multiple application lines to prevent hierarchical queries against the taxonomy table.
By default, the ApplicationLineCriteria will be applied on the view objects exposed on the view object by taxonomy (public and private) with the value of 1 for the Oracle Fusion application line. If you need to get data for another application line, you can set the appropriate value for the bind variable bProductLine.
The service methods use the default Oracle Fusion application line value of 1. The application module APIs that do not accept an application line id assume that the data is being queried for the Oracle Fusion application line.
If you query directly against the taxonomy tables, you must take into account the application line denormalization. You will have to add the filter product_line = <appropriate application line id> to prevent returning multiple rows for a given module key or id.
The following public entity objects are located in the oracle.apps.fnd.applcore.model.publicEntity package and are exposed by Applications Core:
ApplTaxonomyPEO
ApplTaxonomyTranslationPEO
ApplTaxonomyHierarchyPEO
The following public view objects are located in the oracle.apps.fnd.applcore.model.publicView package and are exposed by Applications Core:
ApplTaxonomyPVO: The view object on top of ApplTaxonomyPEO. It has these view criteria exposed:
ProductLineCriteria: Restricts the output to a given Application Line as specified by the bind variable bProductLine. By default, the ProductLineCriteria will be applied on the view objects exposed on the view object by Taxonomy (public and private) with the value of 1 for the Oracle Fusion application line. If you need to get data for another application line, you can set the appropriate value for the bind variable bProductLine.
IsSeedDataAllowedCriteria: where ApplTaxonomyEO.IS_SEED_DATA_ALLOWED=:bIsSeedDataAllowed, where :bIsSeedDataAllowed is a named bind variable with a default value of N.
ApplicationCriteria: Restricts the output to Applications Module Type.
FamilyCriteria: Restricts the output to Family Module Type.
ModuleIdCriteria: Restricts the output to a given module ID as specified by the bind variable bModuleId.
ModuleTypeCriteria: Restricts the output to a given moduleType as specified by the bind variable bModuleType.
ApplTaxonomyTranslationPVO: The view object on top of ApplTaxonomyTranslationPEO. It has these view criteria exposed:
ProductLineCriteria: where ApplTaxonomyEO.PRODUCT_LINE=:bProductLine where :bProductLine is a named bind variable with a default value of 1 – the Oracle Fusion Productline.
IsSeedDataAllowedCriteria: where ApplTaxonomyEO.IS_SEED_DATA_ALLOWED=:bIsSeedDataAllowed, where :bIsSeedDataAllowed is a named bind variable with a default value of N.
ApplTaxonomyHierarchyPVO: The view object on top of ApplTaxonomyHierarchyPEO. It has these view criteria exposed:
ProductLineCriteria: where ApplTaxonomyEO.PRODUCT_LINE=:bProductLine where :bProductLine is a named bind variable with a default value of 1 – the Oracle Fusion Productline.
IsSeedDataAllowedCriteria: where ApplTaxonomyEO.IS_SEED_DATA_ALLOWED=:bIsSeedDataAllowed, where :bIsSeedDataAllowed is a named bind variable with a default value of N.
ApplTaxonomyHierarchyFullPVO: Has a join between the hierarchy table's source_module_id and the taxonomy table's module_id, and between the hierarchy table's target_module_id and the taxonomy table's module_id. This view object is rarely needed. It has these view criteria exposed:
ProductLineCriteria: where ApplTaxonomyEO.PRODUCT_LINE=:bProductLine where :bProductLine is a named bind variable with a default value of 1 – the Oracle Fusion Productline.
IsSeedDataAllowedCriteria: where ApplTaxonomyEO.IS_SEED_DATA_ALLOWED=:bIsSeedDataAllowed, where :bIsSeedDataAllowed is a named bind variable with a default value of N.
ApplicationPVO: This view object is shaped to match the Application view object that was on top of the FND_APPLICATIONS view. Note that FND_APPLICATIONS, which was a table in R12, has now been changed to a view on top of Taxonomy tables. It has these view criteria exposed:
ProductLineCriteria: where ApplTaxonomyEO.PRODUCT_LINE=:bProductLine where :bProductLine is a named bind variable with a default value of 1 – the Oracle Fusion Productline.
IsSeedDataAllowedCriteria: where ApplTaxonomyEO.IS_SEED_DATA_ALLOWED=:bIsSeedDataAllowed, where :bIsSeedDataAllowed is a named bind variable with a default value of N.
ApplTaxonomyFullDeliveryPVO: This View object is a join between the Hierarchy table's source_module_id and the Taxonomy table's module_id. When a self-referential view link is created on this view object between the source_module_id and target_module_id (1..*), it can be used to traverse the taxonomy delivery hierarchy. For more details, see the non-public view object ApplTaxonomyFullDeliveryVO and its view link. It has these view criteria exposed:
ProductLineCriteria: where ApplTaxonomyEO.PRODUCT_LINE=:bProductLine where :bProductLine is a named bind variable with a default value of 1 – the Oracle Fusion Productline.
IsSeedDataAllowedCriteria: where ApplTaxonomyEO.IS_SEED_DATA_ALLOWED=:bIsSeedDataAllowed, where :bIsSeedDataAllowed is a named bind variable with a default value of N.
ApplTaxonomySeedDataPVO — Used for extracting taxonomy seed data. It has these view criteria exposed:
ProductLineCriteria: where ApplTaxonomyEO.PRODUCT_LINE=:bProductLine where :bProductLine is a named bind variable with a default value of 1 – the Oracle Fusion Productline.
IsSeedDataAllowedCriteria: where ApplTaxonomyEO.IS_SEED_DATA_ALLOWED=:bIsSeedDataAllowed, where :bIsSeedDataAllowed is a named bind variable with a default value of N.
ApplTaxonomyApplicationPVO
ProductLineCriteria: where ApplTaxonomyEO.PRODUCT_LINE=:bProductLine where :bProductLine is a named bind variable with a default value of 1 – the Oracle Fusion Productline.
IsSeedDataAllowedCriteria: where ApplTaxonomyEO.IS_SEED_DATA_ALLOWED=:bIsSeedDataAllowed, where :bIsSeedDataAllowed is a named bind variable with a default value of Y.
To access the Entity and View objects, and other taxonomy components, create a new File System Connection to adflib:
In the Resource Palette, open the folder icon and select New Connection > File System as shown in Figure A-2:
Configure the new connection so it resembles the example in Figure A-3:
The new connection will display in the Connections tree, shown in Figure A-4:
The Entity and View objects are located in Taxonomy-Model.jar > Business Components, shown in Figure A-5:
Notes:
The service methods use the default Oracle Fusion Application Line value of 1. The application module APIs that do not accept an application line id assume that the data is being queried for the Oracle Fusion application line unless the API accepts the Taxonomy table primary key moduleId.
The package for the private view objects and the application module conforms to Applications Packaging standards.
The application module is oracle.apps.fnd.applcore.taxonomy.taxonomyService.applicationModule.
The view objects module is oracle.apps.fnd.applcore.taxonomy.taxonomyService.view.
Two methods are exposed in the ApplTaxonomyAMImpl class:
Given a moduleId, this returns the taxonomy node:
public ApplTaxonomyFullDeliveryVORowImpl getTaxonomyModule(Raw moduleId);
Given a moduleType, this returns an array of taxonomy nodes:
public ApplTaxonomyFullDeliveryVORowImpl[] getTaxonomyModules(String moduleType);
To access a taxonomy application module:
Note:
The ApplTaxonomyAMImpl package is oracle.apps.fnd.applcore.taxonomy.taxonomyService.applicationModule.
ApplTaxonomyAMImpl am = (ApplTaxonomyAMImpl)OAApplicationModuleImpl.getFNDNestedService(OAConstants.TAXONOMY_SERVICE,myAM.getDBTransaction());
Where myAM is the application module that you are working with. You can also create an instance of the ApplTaxonomyAMImpl class directly as needed.
To access a taxonomy node for a given application module, you can call the getTaxonomyModule() API on the module ID:
ApplTaxonomyFullDeliveryVORowImpl row = am.getTaxonomyModule(new oracle.jbo.domain.Raw("025000"));
To access the module name for that node, you can make a call to getModuleName():
String moduleName = row.getModuleName();
To access a set of taxonomy nodes for a given module type, you can call the getTaxonomyModules() API:
ApplTaxonomyFullDeliveryVORowImpl[] rows = am.getTaxonomyModules("FAMILY");
The following methods also are exposed:
Given an application short name, return the application ID:
getApplicationId(String shortName);
Given an application ID, return the application short name:
getApplicationShortName(int appId);
These APIs work if the existing data in FND_APPLICATIONS has been migrated to the Oracle Application Taxonomy tables.
The taxonomy delivery hierarchy can be navigated using the accessors for the children and parents.
To obtain the children of the current node, call getChildApplTaxonomyFullDeliveryVO(), as shown in Example A-1:
Example A-1 Obtaining the Children of the Current Node
RowIterator children = row.getChildApplTaxonomyFullDeliveryVO();
while(children.hasNext())
{
ApplTaxonomyFullDeliveryVORowImpl childRow =
(ApplTaxonomyFullDeliveryVORowImpl)children.next();
// Your code here.
}
ApplTaxonomyFullDeliveryVORowImpl parentRow = (ApplTaxonomyFullDeliveryVORowImpl) row.getParentApplTaxonomyFullDeliveryVO();
To obtain the parent of the current node, call getParentApplTaxonomyFullDeliveryVO(), as shown in Example A-2.
Taxonomy MBeans are useful for obtaining information about Oracle Fusion taxonomy, such as domain, application family, application, modules (UI, SOA, Webservices), and admin log configuration. These MBeans are available as Domain Runtime MBeans in WebLogic Server and expose several APIs, each of which provides specific information about the taxonomy of a deployed Oracle Fusion environment. These MBeans are consumed by application teams as utility APIs to verify information about their applications, and are also integrated with other applications. For instance Enterprise Manager for Oracle Fusion uses these APIs for building the discovery user interfaces. Taxonomy MBeans are registered into the application-defined MBeans after the administration server startup.
Types of Taxonomy MBeans
Two types of Taxonomy MBeans are available:
Topology MBean: Provides information about the topology of the Oracle Fusion environment. Topology MBean data is dependent on the domain against which it is tested. In a particular domain, such as Setup, you can have more than one Product Family.
Log Configuration MBean: Provides utilities for configuring logs at both User- and Site-level in an application.
MBeans as viewed from Enterprise Manager are shown in Figure A-6.
Topology MBean
Topology MBean Details:
MBean Name oracle.topology:name=Topology,type=TopologyRuntimeMBean Description Applications Core Topology MBean that provides the information about overall Oracle Fusion Topology
Attributes exposed by Topology MBeans are shown in Table A-4.
Table A-4 Attributes Exposed by Topology MBeans
| Name | Description | Access |
|---|---|---|
|
AllProductFamilyAndDomains |
Gets all domains and product families of an Oracle Fusion instance. |
R |
|
ConfigMBean |
If true, it indicates that this is a Config MBean. |
R |
|
CurrentDomain |
Gets the current domain. |
R |
|
CurrentPillarInfo |
Get the current pillar. |
R |
|
CurrentPillarInstanceInfo |
Returns all information about current PillarInstanceName. |
R |
|
CurrentProductFamily |
Gets the current product family module key list. |
R |
|
CurrentProductFamilyInfo |
Gets the current product family list information. |
R |
|
eventProvider |
If true, it indicates that this MBean is an event provider as defined by JSR-77. |
R |
|
eventTypes |
All the event types emitted by this MBean. |
R |
|
ListOfProducts |
Gets the list of products for the current product family. |
R |
|
objectName |
The MBean's unique JMX name. |
R |
|
PillarDBInfo |
Get the database information for a particular pillar. |
R |
|
Pillars |
Get all the pillars. |
R |
|
ProductFromEachProductFamily |
Gets list of products for each product family. |
R |
|
ReadOnly |
If true, this MBean is read-only. |
R |
|
RestartNeeded |
Indicates whether a restart is needed. |
R |
|
stateManageable |
If true, it indicates that this MBean provides state management capabilities as defined by JSR-77. |
R |
|
statisticsProvider |
If true, it indicates that this MBean in a statistic provider as defined by JSR-77. |
R |
|
SystemMBean |
If true, it indicates that this MBean is a System MBean. |
R |
The operations exposed by Topology MBeans are shown in Table A-5.
Table A-5 Operations Exposed by Topology MBeans
| Name | Description | Parameters | Return Type |
|---|---|---|---|
|
getAllDeployedAppsInfo |
Complete information on the deployed application for a particular product. |
1 |
Array of javax.management.openmbean.TabularData |
|
getAllEnterpriseAppsInfo |
Gets the list of application information for a given product. |
2 |
Array of javax.management.openmbean.TabularData |
|
getAppListFromDeployedDomain |
Get the application information from the deployed domain name. |
1 |
Array of javax.management.openmbean.TabularData |
|
getDependentApps |
Returns dependent applications information on an application from its AppShortName. |
1 |
Array of javax.management.openmbean.TabularData |
|
getDependentMWComponents |
Gets Dependent MW Components for the AppShortName. |
1 |
Array of javax.management.openmbean.TabularData |
|
getDeployedAppInfo |
Complete information on the deployed application given for an Application Short Name. |
1 |
Array of javax.management.openmbean.TabularData |
|
getDeployedDomainFromLogicalDomain |
Gets DeployedDomain information from the LogicalDomain name. |
1 |
Array of javax.management.openmbean.TabularData |
|
getDeployedDomainFromPillar |
Get the deployed domain information of a particular type for a pillar. |
2 |
Array of javax.management.openmbean.TabularData |
|
getDeployedDomainInfo |
Returns a map of domain information for a given domain name. |
1 |
javax.management.openmbean.TabularData |
|
getDeployedDomainByCompositeName |
Get the deployed domain list for a given composite name. |
1 |
Array of javax.management.openmbean.TabularData |
|
getDeployedDomainsByEnvironment |
Returns the list of domains for a particular environment. If the EnvironmentShortName is null, it will return all the deployed domains. |
1 |
javax.management.openmbean.TabularData |
|
getDomainnames |
Gets the list of domain names for a given application short name. |
1 |
Array of java.lang.String |
|
getEndPointInfo |
Gets the external and internal end points for a given application short name. |
1 |
Array of javax.management.openmbean.TabularData |
|
getEndPointInfoFromModule |
Gets the domain external and internal domain end points for a Logical Module Name. |
1 |
Array of javax.management.openmbean.TabularData |
|
getEnterpriseAppInfo |
Gets the list of application information for a given application short name. |
1 |
javax.management.openmbean.TabularData |
|
getEssApplicationInfo |
Gets ESS application information for a given product family module id. |
1 |
javax.management.openmbean.TabularData |
|
getLbasInfo |
Gets the list of LBA information for the given product family. |
1 |
Array of javax.management.openmbean.TabularData |
|
getListOfDeployedApps |
Gets the list of deployed applications for a particular product. |
1 |
Array of java.lang.String |
|
getListOfDomains |
Gets the list of domain names for a given product family |
1 |
Array of java.lang.String |
|
getListOfEnterpriseApps |
Gets the list of applications for a given product. |
2 |
Array of java.lang.String |
|
getListOfLbas |
Gets the list of LBA (module names) for the given product family. |
1 |
Array of java.lang.String |
Log Configuration MBeans
Log Configuration MBean Details:
MBean Name oracle.topology:name=LogConfiguration,type=LogConfigurationRuntimeMBean Description Log Configuration MBean APIs
Attributes exposed by Log Configuration MBeans are shown in Table A-6.
Table A-6 Attributes Exposed by Log Configuration MBeans
| Name | Description | Access |
|---|---|---|
|
ConfigMBean |
If true, it indicates that this is a Config MBean. |
R |
|
eventProvider |
If true, it indicates that this MBean is an event provider as defined by JSR-77. |
R |
|
eventTypes |
All the event types emitted by this MBean. |
R |
|
LogConfigInformation |
Gets the log configuration information at Site level. |
R |
|
objectname |
The MBean's unique JMX name. |
R |
|
ReadOnly |
If true, this MBean is read-only. |
R |
|
RestartNeeded |
Indicates whether a restart is needed. |
R |
|
stateManageable |
If true, it indicates that this MBean provides State Management capabilities as defined by JSR-77. |
R |
|
statisticsProvider |
If true, it indicates that this MBean in a statistic provider as defined by JSR-77. |
R |
|
SystemMBean |
If true, it indicates that this MBean is a System MBean. |
R |
Operations exposed by Log Configuration MBeans are shown in Table A-7.
Table A-7 Operations Exposed by Log Configuration MBeans
| Name | Description | Parameters | Return Type |
|---|---|---|---|
|
addUserLogConfig |
Adds the log configuration information for a particular user. |
8 |
boolean |
|
deleteUserLogConfig |
Delete the log configuration information for a particular user. |
1 |
void |
|
editUserLogConfig |
Edit the log configuration information for a particular user. |
8 |
boolean |
|
getUserInfo |
Gets the user information (the GUID) for users either having or not having the log configuration information. |
2 |
javax.management.openmbean.TabularData |
|
getUserLogConfigInformation |
Gets the log configuration information for a particular user. |
1 |
Array of javax.management.openmbean.TabularData |
|
updateLogConfigInformation |
Update the log configuration information at Site level. |
8 |
void |
Sample Code to Invoke MBean APIs
Sample code is shown in Example A-3.
Example A-3 Sample Code to Invoke MBean APIs
String appShortName = "<ESS/Service Name>";
MBeanServerConnection serverCon =
ServiceLocator.getInstance().getServerConnection(jmxURL,jmxKey);
ObjectName serviceMBean = new ObjectName("oracle.topology:Location=DefaultServer,name=Topology,
type=TopologyRuntimeMBean,Application=Topology");
TabularData domainInfo = (TabularData) serverCon.invoke(serviceMBean,
"getEndPointInfo",
new Object[]{appShortName},
new String[]{String.class.getName() } );
Collection domainProps = domainInfo.values();
Iterator iterator = domainProps.iterator();
while (iterator.hasNext())
{
CompositeData data = (CompositeData) iterator.next();
String AppShortName = (String) data.get("AppShortName");
String CloudName = (String) data.get("CloudName");
String DeployedDomainName = (String) data.get("DeployedDomainName");
String LogicalDomainName= (String) data.get("LogicalDomainName");
String InternalEndPoint = (String) data.get("InternalEndPoint");
String ExternalEndPoint = (String) data.get("ExternalEndPoint");
String AdminEndPoint = (String) data.get("AdminEndPoint");
}
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|