A Working with the Application Taxonomy

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:

This appendix includes the following sections:

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.

A.1 Introduction to the Oracle Fusion Application 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:

Figure A-1 Taxonomy UI Hierarchy Example

Described in the surrounding text.

A.1.1 Characteristics of the Level Categories

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.

A.1.2 How to Manage the Lifecycle

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

A.1.2.1 Creating Patches and Patch Sets

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.

A.1.2.2 System Administration

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.

A.1.2.3 Diagnostics and Maintenance

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.

A.1.3 Benefits of a Logical Hierarchy

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.

A.1.4 Delivery Hierarchy

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.

A.1.5 How to Integrate Taxonomy Task Flows into Oracle Fusion Functional Setup Manager

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

/WEB-INF/oracle/apps/fnd/applcore/taxonomy/ui/taskflow/ViewDeliveryHierarchy.xml#ViewDeliveryHierarchy

[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.


A.2 Working with Objects and Methods in the Application Taxonomy

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?).

A.2.1 Particular Table Columns and Data

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?

CREATED_BY

VARCHAR2(64)

Not Null

CREATION_DATE

TIMESTAMP

Not Null

LAST_UPDATED_BY

VARCHAR2(64)

Not Null

LAST_UPDATE_DATE

TIMESTAMP

Not Null

LAST_UPDATE_LOGIN

VARCHAR2(32)

 

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?

REQUEST_ID

NUMBER(20)

NULL

JOB_DEFINITION_NAME

VARCHAR2(100)

NULL

JOB_DEFINITION_PACKAGE

VARCHAR2(900)

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).

A.2.2 Denormalized Taxonomy Table

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.

A.2.3 Available Public Business Objects

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.

A.2.3.1 Accessing the Entity and View Objects

To access the Entity and View objects, and other taxonomy components, create a new File System Connection to adflib:

  1. In the Resource Palette, open the folder icon and select New Connection > File System as shown in Figure A-2:

    Figure A-2 Creating a New File System Connection

    Described in the surrounding text.
  2. Configure the new connection so it resembles the example in Figure A-3:

    Figure A-3 Configuring a New File System Connection

    Described in the surrounding text.
  3. The new connection will display in the Connections tree, shown in Figure A-4:

    Figure A-4 New File System Connections Tree

    Described in the surrounding text.
  4. The Entity and View objects are located in Taxonomy-Model.jar > Business Components, shown in Figure A-5:

    Figure A-5 Locating the Entity and View Objects in the Connections Tree

    Described in the surrounding text.

A.2.4 How to Use Exposed Service Methods

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.

A.2.5 How to Traverse the Taxonomy Hierarchy

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.

Example A-2 Obtaining the Parent of the Current Row

ApplTaxonomyFullDeliveryVORowImpl parentRow = 
   (ApplTaxonomyFullDeliveryVORowImpl) row.getParentApplTaxonomyFullDeliveryVO();

A.3 Understanding Taxonomy MBeans

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.

Figure A-6 MBeans Viewed from Enterprise Manager

Described in the surrounding text.

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");
}