Anthony Shorten

Over the last few weeks, we have been making changes to improve the usefulness of the technical information for Oracle Utilities products. To this end this blog will be retired and moving under the Oracle Utilities blog banner as a technical channel known as The Tech Spot. So goodbye to TheShortenSpot and hello to The Tech Spot.

This has a lot of advantages:

• This allows you the users of this blog to find all the information about the Oracle Utilities products in one location, the Oracle Utilities blog.
• The contributions to the blog will now expand to other technical personnel to greatly expand the content.

The ShortenSpot twitter and Linked In accounts will also be retired and shifted over to the links contained in the new blog.

I will be posting all new content on this new location rather than this blog. I look forward to seeing you over there.

To quote a famous movie from theShortenSpot "In case I don't see ya, good afternoon, good evening and goodnight. "

In past articles I discussed the Batch Level Of Service capability and one of the most important questions I am asked is how to best implement this for on-premise and cloud implementations. Here are some best advice to use this capability quickly with the minimum of work:

• Target Tolerances. Create algorithm entries using the provided base algorithm types setting your warning tolerance and error tolerance for each target value and method of evaluation. These represent the target values for warnings and error tolerances based around metrics like elapsed time, error rate, throughput etc. Remember these algorithm types are reusable across many batch controls.
  • The base algorithms support a warning and an error tolerance. They also supporting using the latest completed or in progress execution. The latter is useful for live tracking during the execution.
• Link Targets to Batch Controls. Add the appropriate algorithm (with the appropriate target value) as the Batch Level Of Service algorithm. Multiple algorithms are also supported for the algorithm to cater for multiple criteria. To optimize the effort in managing the configuration of Batch Control's it is recommended to:
  • Configure the most important or critical jobs to your business first. This is an important subset to focus upon.
  • Configure the other processes as needed. Not all batch controls need targets.

The Batch Level Of Service will now be assessed against the latest execution (depending on the configuration of the algorithm itself) and the target values returning the relevant status.

Once you configure those targets you can use the Health Check Screen (or REST API for integration to other monitoring tools) and other capabilities to determine the batch level of service. For example:

Note: In the Oracle Utilities Cloud Services you can set the level of service on the schedule itself to check batch windows.

For more information about the Batch Level Of Service, refer to the following related articles:

• Configuring Batch Level Of Service
• Building A Batch Level Of Service Algorithm
• Using Batch Level Of Service - Batch History Portal
• Calling a Batch Level Of Service

The Oracle Utilities Testing Accelerator was introduced over a year ago and the tool continues to be popular with customers and is included in all Oracle Utilities SaaS Cloud Services available on Oracle Cloud Infrastructure. The tool takes a different approach to providing testing capabilities that other types of testing tend to not offer.

There are three regimes of Testing that applies to Oracle Utilities products:

• Manual Testing. This is the baseline where a group of human testers simply use the product and test it manually. Whilst this is a valid way of testing for a lot implementations, it is high cost (due to the labor cost involved) and high risk as it tends to be timeboxed, to meet deadlines, so things are missed in the testing. When regular upgrades are involved it may soon become harder to sustain.
• Automated Testing (also known as Traditional Automation). Over the last decade or so, automated testing tools have been appearing on the market to try and reduce the manual effort involved in testing. They tend to concentrate on recording screens, creating scripts from those recording and embedding data into those scripts. The idea then is that recording can be played back over and over again. Some vendors have tried to separate the data from the script to make it reusable with different data, No matter what though they have a fundamental flow in that they only test online and any change to the online screens, for ANY reason, means manually manipulating the script or re-recording it. This means time to test (the time from installing to actually testing) in each iteration had to include refactoring test asset changes.
• Component Based Approach with PreBuilt Assets. This is where Oracle Utilities Testing Accelerator takes the advantages of automation but addresses the time to test concerns. The Oracle Utilities Testing Accelerator provides prebuilt content from Oracle which reduces test asset building times, tests all channels used in Oracle Utilities including online, batch, web services and mobile. Those assets tend to be upgradeable automatically (using the Oracle Utilities philosophy of backward compatibility) to retain their usefulness and save costs. The product also uses an orchestration metaphor to build tests rather than programming to reduce technical skills needed for the tool.

The figure below summarizes the discussion above:

The Oracle Utilities Test Accelerator is a testing solution optimized for use with Oracle Utilities product suite with prebuilt content including the Oracle Utilities Reference Model. It is available for on-premise use and now is included in all Oracle Utilities SaaS Cloud Services.

It is possible to extend the Oracle Utilities Testing Accelerator with custom components and custom libraries. This allows customers to include their extensions that may not be supported by a base supplied prebuilt test asset. The capability allows for the following:

• Building Custom Components on Base Capabilities. Whilst the packs provide the majority of the base functionality, some functions may not be available in the release of the pack you are using. Instead of waiting for that function to be released, you can use this capability to build a custom component to continue testing.
• Building Custom Components on Extensions. This is the most common use case where there is not a provided pre-built component that does not cover your extension. Generally if your extension alters the structure (schema) of the product, not just with data, then a custom component is required to educate the Oracle Utilities Testing Accelerator how to interface to the extension.
• Building Custom Libraries. The Oracle Utilities Testing Accelerator ships with a library of functions to allow manipulation or generation of individual data. Custom libraries can be build inside the tool, using Groovy, to add your own functions, if necessary.

There is a whitepaper that outlines, with examples, the process for all of the above is now available for customers and partners using Oracle Utilities Testing Accelerator.  The UTA - Building Custom Components And Functions for Oracle Utilities Application Framework Based Products (Doc Id: 2662058.1) is available from My Oracle Support.

The Oracle Utilities Testing Accelerator uses a unique approach to test automation for Oracle Utilities products, which uses techniques and content used at Oracle, to reduce risk and cost in taking advantage of test automation over traditional methods. Give this unique approach the techniques used in traditional automation need to be optimized to take full advantage of the platform and prebuilt content provided by the Oracle Utilities teams.

Developing a coherent test strategy as part of your initial implementation of test automation. This strategy will outlines objectives, techniques and set the stage for using test automation to meet that strategy.

A whitepaper from the developers of Oracle Utilities Testing Accelerator is now available from My Oracle Support titled UTA - Test Strategy Best Practices Guidance for Oracle Utilities Application Framework Based Products (Doc Id: 2659556.1).

This whitepaper summarizes the following:

• Discussions of the different types of testing to be considered part of a strategy taking into consideration of the Oracle Utilities Testing Accelerator. This introduces a typical quadrant system with the standard principle "Do the High importance and High Value Business Processes First". For example:

• Techniques for designing test scenarios and test cases to take advantage of Oracle Utilities Testing Accelerator prebuilt content including the Oracle Utilities Reference Model content.
• Techniques to consider when designing test data to be used in testing including generation of data, importing data and how to manage that data effectively to help maximize reuse.

This whitepaper is part of a series which includes existing whitepapers and set of new whitepapers to outline common practices when using the unique approach used in the Oracle Utilities Testing Accelerator.

The installation of an on-premise version of Utilities Testing Accelerator (UTA) has been improved upon in both versions 6.0.0.1.0 and 6.0.0.2.0 to allow customers to quickly establish product environments. This article is a summary of this process, which is also outlined in the Oracle Utilities Testing Accelerator installation Guides.

Prerequisites

Before installing there are a number of prerequisites necessary for the installation:

• Database. The database to house the Utilities Testing Accelerator objects must be available and accessible to the server you want to install Utilities Testing Accelerator upon. This an be local or remote and can be a separate schema or a PDB in the same location as the Oracle Utilities product. Utilities Testing Accelerator supports the UTA Repository as a separate schema existing on a PDB or non-PDB database or even as a separate PDB on the Multi-tenant database. It does not require any database access to the Oracle Utilities products it is being used against.

Note: The Oracle Utilities Testing Accelerator does not ship with a database license and reuses the existing database license for supported Oracle Utilities products. Customers with Unlimited License Agreement licenses for the Oracle Database have lesser restrictions in this regard.

• Java. The Java JDK or JRE must be installed on the machine that will house Utilities Testing Accelerator. A Java support license is included with all Oracle products including Oracle Utilities Testing Accelerator.
• XWindows. The Oracle installer used by the Oracle Utilities Testing Accelerator uses XWindows. This is the same installer used by Oracle Database and Oracle WebLogic and a host of other Oracle products so staff familiar with those products will be familiar with the installer.

A few years ago I published a set of guides for Performance Troubleshooting Oracle Utilities Application Framework based products for on-premise implementations. These guides outlined the metrics and capabilities to monitor those products as well as general advice from our Black belt teams. The whitepapers have been updated with the following changes:

• The guides have been rewritten to flow better and make them easier to understand. This was based upon feedback from partners and customers.
• Some of the guides have been combined from the previous releases to save on duplicate information.
• The guides now include a lot more links to more detailed information. A Related Reading section is on the top of each topic to point you to very important advice on each topic available on the Oracle Support site. This is to keep the information up to date and help you with understanding the support process.
• The guides have been updated for the latest releases for the Oracle Utilities Application Framework.
• Some of the advice has been removed that was deemed out of date or not relevant to Oracle Utilities Application Framework products anymore.

The guides are split into a number of documents:

• Concepts Guide. Introduces the topics and some key concepts used in the series.
• Client Monitoring. Monitoring the browser client and some advice on setting up the browser.
• Application Server Monitoring. Monitoring the Oracle WebLogic domain components used by the Oracle Utilities Application Framework. This guide strictly only covers the components directly used by the Oracle Utilities Application Framework within the domain. This used to be a number of guides now combined into one guide.
• Batch Monitoring. Monitoring the batch architecture including Coherence monitoring.
• Database Monitoring. Monitoring the Database components. This whitepaper is a companion to the Database documentation and the DBA Guides shipped with each product.
• Server Monitoring. Monitoring the CPU, Memory and Disk access with tolerances recommended by Oracle generically for those components.
• Network Monitoring. Monitoring the network to the server and within the server architecture.

The Performance Troubleshooting Guides are available from My Oracle Support at Doc Id: 560382.1.

 

Oracle is delighted to announce the availability of exclusive content within Oracle Utilities Testing Accelerator for the Oracle Utilities Reference Model. This means that the Oracle Utilities Testing Accelerator has flow packs available representing the processes implemented by the Oracle Utilities Reference Model.

The Oracle Utilities Reference Model was originally released as documentation a few years ago and represents generic common practices for business processes, typically experienced by a range of utilities across the world. The models are maintained by a specialist team within the Oracle Utilities development organization and were popular with partners and customers alike keen not only to implement Oracle Utilities products but benefit from these pre-built business models.

Since the inception of the models, it has been a goal to make them more usable and more relevant to a wider Oracle Utilities customer audience. Inspired by the flow and component pack experiences with Oracle Application Testing Suite, which realized significant cost and risk savings, there was a strategy to express the models in the Oracle Utilities Testing Accelerator as an exclusive content pack.

With the inclusion of the Oracle Utilities Reference Model content, Oracle Utilities Testing Accelerator customers not only have access to pre-built product components but now have access to flows representing best practices for using Oracle Utilities products. The flows are designed using the features of the latest release of the Oracle Utilities Testing Accelerator with flow fragments and complete flows, so that customers can get to testing quicker and with lower risk and costs.

The release of the Oracle Utilities Reference Model content not only includes the test assets but comprehensive documentation on how to best use those assets to test more effectively.  

Customers who licensed the Oracle Utilities Testing Accelerator are also licensed to use this Oracle Utilities Reference Model pack with the relevant product packs and can down the pack and related information from Oracle's documentation site and Patch 30427094 for updates to the Testing API from My Oracle Support.

Note: This content is updated regularly so check the above site for new content and new releases.

Note: The first release of the pack will be exclusively based around the Oracle Utilities SaaS Cloud Services. With subsequent releases covering additional processes and on-premise customers.

Note: Oracle Utilities SaaS Cloud Service customers will receive the pack in the next relevant patch window in included Oracle Utilities Testing Accelerator instances included in that service.

For more information about Oracle Utilities Testing Accelerator, refer to Oracle Utilities Testing Accelerator Overview (Doc Id: 2014163.1) from My Oracle Support which includes an overview and a Frequently Asked Questions.

In Oracle Utilities Testing Accelerator 6.0.0.1.0, the server based execution engine was introduced, as the default execution engine, to complement the original Eclipse based engine. This engine was restricted to a single manual execution of a flow with the related data. In this release, the engine has been expanded to not only support Flow Test Data Sets and Flow Subroutines but to support multiple executions, also known as Iterative Executions. This capability allows multiple test executions to be executed iterating through relevant Flow Test Data Sets. This allows testers to test complex scenarios or simply prepare data for other tests.

When specifying an execution, there is now a Iterative execution type that allows number of iterations and the list of available Flow Test Data Sets to use for the iterations. For example:

For more information about Iterative Execution, refer to the Flow Subroutines and Test Data Sets whitepaper (Doc Id: 2632033.1)  available from My Oracle Support.

For more information about Oracle Utilities Testing Accelerator, refer to Oracle Utilities Testing Accelerator Overview (Doc Id: 2014163.1) from My Oracle Support which includes an overview and a Frequently Asked Questions.

With the release of Oracle Enterprise Manager 13.4, the Enterprise Manager for Oracle Utilities has been re-certified and updated to take advantage of the new and exciting capabilities of Oracle Enterprise Manager. This release extends the reach of the Enterprise Manager to both on-premise and Oracle Cloud IaaS/PaaS with native support for the new Oracle Cloud Infrastructure. This ensures customers transitioning from on-premise to Oracle Cloud IaaS/PaaS implementations can transition their monitoring to the same infrastructure.

Oracle Enterprise Manager also includes additional tools for migrating more easily from on-premise to Oracle Cloud IaaS/PaaS implementations.

For more information about Oracle Enterprise Manager 13.4 refer to the release notes and for more information about Enterprise Manager for Oracle Utilities refer to the documentation.

One of the most common sets of questions I get from partners and customers are things like "How do I set up Load Balancing with your products?" or "How do link my security repository to your products?". People are surprised by my response by linking to the Oracle WebLogic and Oracle Database documentation.

This emphasizes the confusion over the role of the infrastructure versus the application. Let me explain. The Oracle Utilities products are applications housed in a container such as Oracle WebLogic and store their data in the database, namely Oracle Database. These are infrastructure and Oracle Utilities products should not be confused with them as it is an application using these services. Infrastructure provides a series of services that interface to the operating system and provide services to the application housed with them. There is a role for infrastructure and a role for applications housed in infrastructure.

These infrastructure services provide the interface into a lot of capabilities that the applications. Some of the capabilities provided are:

• Security. Oracle WebLogic is responsible for the direct security of the applications that it houses. It provides a wide range of connectors to security such as its own internal LDAP server, external LDAP based repositories, SSO, OAuth2 and other security repositories. Oracle WebLogic provides the authentication and policy services for all the channels used by the Oracle Utilities products.
• High Availability. Oracle WebLogic and the Oracle Database supports a large variety of architectures including high availability architectures, such those outlined in Oracle's Maximum Availability Architecture. The Oracle Utilities products can take advantage of this capability for high availability and scalability by being housed in a highly available Oracle WebLogic or Oracle Database cluster. This includes the ability to support the various hardware and software load balancers supported by Oracle WebLogic and Oracle Database.
• JMS, Oracle WebLogic includes an inbuilt scalable JMS capability. This capability can be used by the Oracle Utilities products for inbound and outbound communications directly or via middleware.
• JDBC. Oracle WebLogic includes basic and advanced capabilities when connecting to the Oracle Database via JDBC. The Oracle Utilities products can take advantage of both the basic and advanced capabilities offered by these drivers.
• Other capabilities. Oracle WebLogic offers a wide range of additional capabilities that can be utiltized by the Oracle Utilities including caching, specialist networking etc.

Remember the role of the application is to provide functionality for the business, the role for the infrastructure around the application is to support the application and its interfaces to the various capabilities provided by that infrastructure.

It is not the responsibility of the product to take over the role filled by the infrastructure. A simple example I use with people is that you don't expect MSPaint to have the capability to change your Windows Password. Windows itself provides that capability and MSPaint provides user with the capability to compose and manipulate graphics.

If you want to remind yourself, always remember that the application is housed in a container, in the case of Oracle Utilities products that container is Oracle WebLogic. To get into that container to the application, you must go through that container.

My recommendation to partners and customers is to learn as much as you can about the capabilities of the infrastructure before learning about the capabilities of the application to avoid confusion.

In Oracle Utilities Testing Accelerator 6.0.0.1.0 we introduced the concept of saved and reusable Component Test Data Sets which represents reusable test data at a component level. The idea is that as you use a component you can design different reusable test data sets and save those for reuse across flows. This data can be manually entered in the workbench, imported from an environment and/or generated using keyword/tag libraries provided by the product teams. This was very useful and allowed data experimentation to test different scenarios.

Based upon feedback from our customers and partners, this capability has been expanded, in Oracle Utilities Testing Accelerator 6.0.0.2.0 to now allow for test data sets to be associated with flows as well as components. This means you can group a series of component test data sets into a flow based test data set for reuse across instances of that flow.

This translates to greater configuration and greater levels of control. For example, you can now design a set of reusable test data that simulates a specific type of customer or type of business scenario you want to test a flow against. This can be saved as a named Flow Test Data Set and reused whenever that flow is executed. For example:

This enhancement allows for maintenance of the Component Test Data Sets at an individual level and when they are used as a part of the Flow Test Data Set. Whenever a Flow Test Data Set is used then it is indicated on the user interface. For example:

The introduction of Flow Test Data Sets is strategic to encourage reuse and manage the Test Data in a more cost effective way within the workbench.

For more information about Flow Test Data Sets, refer to the Flow Subroutines and Test Data Sets whitepaper (Doc Id: 2632033.1)  available from My Oracle Support.

For more information about Oracle Utilities Testing Accelerator, refer to Oracle Utilities Testing Accelerator Overview (Doc Id: 2014163.1) from My Oracle Support which includes an overview and a Frequently Asked Questions.

The installation of an on-premise version of Utilities Testing Accelerator has been improved upon in both versions 6.0.0.1.0 and 6.0.0.2.0 to allow customers to quickly establish product environments. This article is a summary of this process, which is also outlined in the Oracle Utilities Testing Accelerator installation Guides.

Before installing there are a number of prerequisites necessary for the installation:

• Database. The database to house the UTA objects must be available and accessible to the server you want to install UTA upon. This an be local or remote and can be a separate schema or a PDB in the same location as the Oracle Utilities product. UTA supports the UTA repository as a seperate schema existing on a PDB or non-PDB database or even as a separate PDB on the Multi-tenant database. It does not require any database access to the Oracle Utilities products it is being used against.
• Java. The Java JDK or JRE must be installed on the machine that will house UTA. A Java support license is included with all Oracle products including Oracle Utilities Testing Accelerator.
• XWindows. The Oracle installer used by the Oracle Utilities Testing Accelerator uses XWindows. This is the same installer used by Oracle Database and Oracle WebLogic and a host of other Oracle products so staff familiar with those products will be familiar with the installer.

Note: XWindows is supported natively or via virtualization such as VNC.

The Oracle Utilities Testing Accelerator is available for on-premise customers from Oracle Software Delivery Cloud and includes the documentation and software:

After downloading the software from Oracle Software Delivery Cloud, the following steps are performed:

• Create Database Resources. Create the UTA schema user (UTA) and tablespaces in the database to house the UTA Repository objects using the database tool of your choice as per the installation guide. The installation guide outlines the minimum setup for UTA. Alter as your site standards. Remember the database settings used as the installer will ask you for them later.

Note: The SQL below are examples only and can be altered to suit site standards.

Database Resource Example SQL Data Tablespace CREATE TABLESPACE uta_data DATAFILE '' SIZE 500M AUTOEXTEND ON NEXT 200M MAXSIZE 1024M DEFAULT STORAGE ( INITIAL 10M NEXT 1M pctincrease 10 ) permanent online logging; where <datafile> is the location and filename in Oracle database to store the Oracle Utilities Testing Accelerator repository. Index Tablespace CREATE TABLESPACE uta_idx DATAFILE '' SIZE 250M AUTOEXTEND ON NEXT 50M MAXSIZE 512M DEFAULT STORAGE (INITIAL 10M NEXT 1M PCTINCREASE 10) PERMANENT ONLINE LOGGING; where <indexfile> is the location and filename in Oracle database to store the Oracle Utilities Testing Accelerator repository.

• Execute the Installer. Within XWindows as an appropriate user (usually the same user used to install Oracle Utilities products), execute the installer command. If this command fails, examine the logs and correct the error. The command to start the installer is as follows:

java -jar UTA_6.0.0.2.0_generic.jar

• The Welcome Page is displayed outlining the steps that the installer will follow. Click Next to start the process. For example:

• Inventory Location. As per Oracle products provide the location of the Inventory directory and the group used for the installer. This will default to the group used by the user that initiated the install but can be altered to a group you desire. Click Next after providing the information. For example:

• Installation Location. Provide the directory you want to install the product into. This is effectively the UTA home directory. Click Next after specifying a location. For example:

• Java Home and Application Details. Provide the following information as requested by the installer:
  • Java Home. Home location of the java JDK/JRE for use with Oracle Utilities Testing Accelerator. This will default to the location used for the installer but may reference other java installations if required.
  • Application Server Port. The port number to be used by the Oracle Utilities Testing Accelerator. Default: 8082.
  • Application Administrator User Name. The default user for the administrator. This is the initial user used to create other users. Default: system
  • Application Administrator User Password. The password (and confirmation password) for the Application Administrator User Name.

Note: This is NOT the database system user. It is a user defined to the Utilities Testing Accelerator product.

Click Next after specifying the information.

• Application Keystore Details. As with all Oracle products, the Oracle Utilities Testing Accelerator is installed in secure by default mode. For this to occur a default keystore needs to be generated as part of the process. The information provided generates a unique key used by UTA for communications and encrpytion. Therefore the following information, used by the keytool utility for X.500 generation, via the RFC1779 standard, needs to be provided.
  • Common Name. Name of the organization, machine name (for machine scoped installs) or company root website name. For example: utility.com
  • Organization Unit. Name of Unit associated with use of Utilities Testing Accelerator.
  • Organization Name. Name of company (not web site name)
  • City. Name of Suburb or city.
  • State. Name of State
  • Country Code. The ISO-3166 2 character country code. Default: US (for USA). For other codes, refer to the ISO standard.
  • Keystore Password. Password (and confirmation) to secure keystore. This is used by the product to access the keystore.

Note: It is possible to replace the keystore after installation if your site has a company keystore. Refer to the UTA documentation for post installation steps on how to replace the default keystore and use advanced keystore attributes.

Click Next after specifying the information.

• Target Database Connection Details. Provide the details of the database you want to use for the installation of the UTA Repository. The following information needs to be provided:
  • Database Host. The host name housing the database to house the UTA Repository.
  • Database Port. The listener port number of the database to house the UTA Repository.
  • Database Service Name. The PDB name or database service name of the database to house the UTA Repository.
  • Database Administrator User Name. The DBA user to be used to install the UTA Repository objects. This user MUST have DBA access to create the objects.
  • Database Administrator Password. The associated password (and confirmation) for the DBA user.
  • Application Database Schema Password. The password (and confirmation) for the UTA schema user created in the prerequisite steps.

Click Next after specifying the information.

• Installation Summary. A summary of the information provided is presented prior to executing the Installation. Click Install to start the installation. For example:

• Installation Progress. The installation will be visually shown with progress. If any steps error refer to the log outlined in the previous step. Correct and restart. An example of the Installation Progress is shown below.

• Installation Complete. A dialog will link to the success or failure of the installation process with a link to the log (if desired). Click Finish to close the installer. For example:

After finishing the install it is possible to start UTA using the following commands:

• Navigate to the home directory specified on Page 3 of the installation (Oracle Home) as the user that installed UTA.
• Use the ./startUTA.sh command to start UTA.

Manual Post Installation Steps

The default certificate generated by the installation is limited in its use. It can be replaced or changed using the following process:

• After logging into UTA use the browser to view and export the certificate to your local drive. For example:

• Alter the certificate as necessary using your sites preferred certificate editor.
• Copy the file to the UTA server and execute the following command to set the certificate:

keytool -import -alias <aliasname> -keystore <certificate store location> -file <certificate location>

Where

• <aliasname> - The alias in the keystore to replace. For UTA this value is typically uta
• <certificate store location> - The store location which is the UTA home directory and keystore name utaKeystore.jks
• <certificate location> - The location of the file you altered.

Note: You will be prompted for the keystore password when executing this command.

Note: Other Cacerts can be found in your JDK location under $JAVA_HOME/jre/lib/security subdirectory.

Common Operations

The following commands are available from the UTA home directory.

Command Operation ./startUTA.sh Starts the Utilities Testing Accelerator ./stopUTA.sh Stops the Utilities Testing Accelerator ./startUTARuntimeExectutor.sh Starts the Server Execution Engine ./stopUTARuntimeExectutor.sh Stop the Server Execution Engine UTA Eclipse Client

Note: Use of this client is optional as the Server execution is the preferred method of execution.

The UTA Eclipse client is located in the UTA Home directory and is named UTA_Client.zip. Download it from this location and refer to the installation guide for additional instructions for sites wanting to use this client.

One of the most innovative new capabilities introduced into the Oracle Utilities Testing Accelerator (6.0.0.2.0 and above) is the support for Flow Subroutines. The key concept to understand that it is now possible, using this capability, for any flow to be reused within another flow, yet still retain independence. This is a very useful to allow test engineers to model repeatable processes and reuse those processes across test assets more effectively.

The concept has a key capability in the form of the Subroutine Interface. This takes a flow and defines the interface and the amount of data sharing within the flow it is included in. You can define the Inputs and Outputs from the flow in this interface. More importantly, it allows this specification to be optimized for the flow it is to be embedded in. This opens up a lot of possibilities. You can take a common flow, test it independently, and then include it in any way into other flows. It can be the initial part of another flow, somewhere inside the flow or at the end of the flow. In each style you can define how that subroutine flow interacts with the flow it is embedded in.

The most interesting part of this enhancement is that flows do not have to be designed to be reused. They can be designed to be used as is and then reused as needed. This means as test assets are built you can choose to design them as you wish and use subroutines where appropriate. The end execution is the same with the same information processed whether it is embedded or simply included in the flow.

Customers familiar with Oracle Application Testing Suite will be familiar with Component Groups. These were reusable groups of components you placed into flows, designed for reuse. When we built the Oracle Utilities Testing Accelerator on the design of the Oracle Application Testing Suite design, we decided not to implement Component Groups. We found the idea that you had to design an asset you could only used one way, limiting, so we decided to add Flow Subroutines as an alternative. This has the same reuse concept as Component Groups but left the assets as reusable and independent. We felt it was the best in both worlds.

When we opened up Oracle Utilities Testing Accelerator to the Oracle Utilities Reference Model, working with that team made the concept we had more relevant. The Oracle Utilities Reference Model content pack use this Flow Subroutine to support a wider range of use cases and utility types than ever.

The use of Flow Subroutines is optional but we have extended the Oracle Utilities Testing Accelerator workbench to not only allow flows to be built, but their interface when using them as a subroutine to be done.

Let me illustrate the power of this capability using an example. Here we have three generic simple flows.

As you see, the grouping of Component A, Component B and Component C are common to each flow. They are in different places in each flow but the sequence is the same. Now this is a perfectly normal situation and you can execute these flows as per this configuration. The grouping of Component A, Component B and Component C might represent a common sequence of events you repeat in different processes. The disadvantage of repeating this group of components is that if you want to change across the flows you would have to edit it a number of times.

With the introduction of flow subroutines you would create a new flow holding those common components. This flow can be executed separately to test the sequence and becomes a flow in its own right. The new flow would look something like this:

Now you would edit the original flows to now replace the original sequences with this new flow as a flow subroutine.

You will notice that as part of replacing the components with a flow we needed to add a flow subroutine interface. This happens when you include a flow into another flow and defines the interface (what data is passed between flows) based upon their context.

• In the first flow example, the flow subroutine is at the start of the flow, so you will define the output from the subroutine exposed to the rest of the flow.
• In the second flow example, the flow subroutine is in the middle of the flow, so you need to define the input and outputs in context of the flow.
• In the third flow example, the flow subroutine is at the end of the flow you just need to define the data input into the flow.

As pointed out, any flow can be used as a subroutine within another flow and the flow subroutine interface defines the interactions between the flow and its subroutines depending on the context of the test.

For more information about Flow Subroutines, refer to Flow Subroutines and Test Data Sets (Doc Id: 2632033.1) available from My Oracle Support

For more information about Oracle Utilities Testing Accelerator, refer to Oracle Utilities Testing Accelerator Overview (Doc Id: 2014163.1) from My Oracle Support which includes an overview and a Frequently Asked Questions.

Oracle is delighted to announce the release of the Oracle Utilities Testing Accelerator (UTA), known as Version 6.0.0.2.0, is now available for licensed customers to use. This release is significant as it is considered a foundation release for customers who wish to use the upcoming Utilities Reference Model (URM) content. This release realizes one of the major goals of the Utilities Testing Accelerator by providing reusable content with the tool to greatly reduce risk and costs of implementing Oracle Utilities products. This also contrasts the premise of traditional automation tools where the risk and cost is still with the testers on building and maintaining content.

This release contains the following major enhancements:

• Foundation Release. This release is required as a minimum for customers considering to use the Oracle Utilities Reference Model UTA content packs. It is highly recommended that UTA customers upgrade to this release prior to using the Oracle Utilities Reference Model content. A subset of this pack is shown below:

Note: The Utilities Reference Model content will not work on older versions of the Oracle Utilities Testing Accelerator. The initial release of the Oracle Utilities Reference Model pack is targeted at Oracle Utilities SaaS Cloud Services only. In subsequent releases of the pack other variations, including on-premise releases, will be supported.

• Flow Test Data Set Support. In prior releases, it was possible to associate test data set content with individual components within a flow for reuse. In this release, test data sets can be associated as a flow data set that is associated with flows. Once established, the flow test data sets can be managed and used as a set at anytime. This reduces data management at a flow level and promotes reuse. This is a foundation feature for the upcoming test planning capabilities planned in future releases. For example:

For more information about Flow Test Data Sets, refer to Flow Subroutines and Test Data Sets (Doc Id: 2632033.1) available from My Oracle Support.

• Iterative Flow Support. In some test scenarios, multiple flow executions are needed to populate enough data for additional tests. In this release, it now possible at the Flow Group level to iterate a flow using different data banks to populate data in a single execution event. This capability is used in association with Flow Set Support to easily target relevant data with each iteration. For example:

• Flow Subroutine Support. To promote reuse, it is now possible to include a flow within a flow, in a similar method to components. This allows flows to model specific micro-level business processes and then incorporated into longer duration process to reduce testing costs and encourage reuse. Customers familiar with Oracle Application Testing Suite might remember Component Groups that had similar concepts. Oracle Utilities Testing Accelerator does not support Component Groups as we wanted to take advantage of the concepts and capabilities of the flows rather than groups of components. For example, flows can act as standalone and/or subroutines and can be independently executed. The Oracle Utilities Reference Model content fully exploits this capability. This allows implementation to treat a flow as a subroutine with a configurable Subroutine Interface uniquely on each reuse. This means that Flows can be standalone and/or reused wherever appropriate with a configurable interface to maximize reuse. For example:

For more information about Flow Subroutines, refer to Flow Subroutines and Test Data Sets (Doc Id: 2632033.1) available from My Oracle Support.

• Improvements to the User Experience. With each release of the product, the user interface is improved based upon feedback from existing customers and in direction of our UX design team. In this release the following has been updated:
  • Updated Oracle Jet Library. The rendering engine and libraries used for the product have been updated to the latest Oracle Jet release to offer greater browser compatibility, to address user experience inconsistencies and offer new capabilities.
  • Dynamic Zone Sizing. To support a wider range of form factors the user zones can by dynamically resized at run-time.
  • Zone Hiding Support. To maximize the effectiveness of the flow and component maintenance, it is now possible to hide the flow/component tree zones to maximize the canvas.
  • Improved Error Messages. As part of the standardization,  messages from the product are progressively migrated to a new panel style interface. For example:

• Inbuilt Purge Capability. With the inclusion of additional data capabilities such as test data sets at component and flow level as well as results for all executions, data retention needs to be managed. This release includes a generic purge capability for test data sets and execution information to keep the database manageable. This is the first in a series of inbuilt data management capabilities planned for the product. For example:

• Improved Categorization of Flows. With the introduction of the new capabilities and the Utilities Reference Model the module system has been extended to allow users to manage their own modules to aid in organization of test assets. A Default module is now shipped with all packs to act as a default capability. In this release the implementation of flow modules has been restricted to a single level. This is planned to be expanded in future releases. For example:

• Improved Email Results Component. For backward compatibility, Oracle Utilities Testing Accelerator supplied an optional component to email a summary of the results. In this release this component has been altered to provide additional information in the email including performance metrics, request payload and response payload. Use of this component is optional as all this information is also available from the results section of the Oracle Utilities Testing Accelerator Workbench and the associated optional eclipse plugin.
• Improved Results Reporting. The results user experience has been revampled in anticipation of the planned Test Planning capabilities in future releases. This interface makes the results easier to understand with more summary screens to save the need to look into details. For example:

There are additional enhancements and fixes from previous versions of the product. For a full list refer to the provided documentation.

For on-premise customers this release will be available from Oracle Software Delivery Cloud and cloud customers will receive this release and content automatically as scheduled. Content Packs are available on-premise customers via My Oracle Support.

For more information about Oracle Utilities Testing Accelerator, refer to Oracle Utilities Testing Accelerator Overview (Doc Id: 2014163.1) from My Oracle Support which includes an overview and a Frequently Asked Questions.

As the Product Manager for a number of products including Oracle Application Management Pack for Oracle Utilities, the Oracle Enterprise Manager plugin for managing Oracle Utilities Application Framework product there are always a number of requests that come across my desk that need clarification. I wanted to post a few responses to some common issues we are seeing in the field and how to address them.

• Read the Installation Documentation. This is obvious but the installation documentation not only talks about the installation of the pack but also what features to enable on the Oracle Utilities Application Framework to maximize the benefits of the pack. For customers on older versions of the Oracle Utilities Application Framework, some of the advanced features of the pack are not available as those versions of the Oracle Utilities Application Framework do not exist. For example, most of the metrics were added in Oracle Utilities Application Framework 4.x.
• Clustering Support Changes. In earlier versions of Oracle Utilities Application Framework with older versions of Oracle WebLogic, to use clustering you needed to use the localhost hostname. Whilst this worked for those versions (and has been used with later version), Oracle recommends to use the actual host name in the configuration and in particular for the JMX integration used by the Oracle Utilities Application Framework. Using localhost in the host name may prevent Oracle Enterprise Manager and the pack recognizing the active ports and will result in the target not being recognized.
• Native Install Transition. A few years ago, the Oracle Utilities Application Framework transitioned to use Oracle WebLogic natively rather than the original embedded mode which was popular in legacy versions of the product. The main reason for moving to native mode was to allow customers full flexibility when using the Oracle WebLogic Domain so that the license value was increased and advanced configuration was supported. To support that transition a decision was made in respect to the pack:
  • Embedded Mode Customers. It is recommended that customers still on the old embedded mode that have not transitioned to a native installation, yet, use the Start / Stop functionality on the Oracle Utilities targets to manage the availability of Oracle Utilities targets. 
  • Native Mode Customers. Customers who have transitioned to the native installation are recommended to use the Oracle WebLogic targets to start and stop the product (as this is one of the benefits of the native mode). It is NOT recommended to use the start and stop functionality on the Oracle Utilities targets during the transition period. The current release of Enterprise Manager and the Application Management Pack for Oracle Utilities cannot manage cross targets at the present moment.

Essentially, if you embedded mode then use the start/stop on the Oracle Utilities targets, if you are native use the start/stop on the Oracle WebLogic targets.

For customers and partners attending the Oracle Utilities Customer Edge Conference in London next month, I will be presenting the Cloud and Technology sessions this year.

The cloud sessions will cover the Oracle Utilities SaaS offerings including advice on migrating from an on-premise implementation to those offerings. The technical sessions will deep dive on our technology strategy/roadmap, a discussion of the new version of Utilities Testing Accelerator including the roadmap and a discussion about our exciting plans for integration of machine learning into our Oracle Utilities product set. Some of these sessions will include short demonstrations of capability and prototypes of exciting new capabilities.

For those attending, feel free to introduce yourself while I am there. See you in London!!

Additionally, I will be presenting a subset of the same sessions late in July at the Oracle Utilities Customer Edge Conference in Melbourne.

One of the features that has been changed over the last few releases of the Oracle Utilities Application Framework has been security. To keep up with security requirements across the industry, the Oracle Utilities Application Framework utilizes the security features of the infrastructure (Operating System, Oracle WebLogic and Oracle Database) as well as provide inbuilt security capabilities. One of the major capabilities is the support for Hash Keys on the user identity.

On the user object, there is a hash key that is managed by the Oracle Utilities Application Framework. The goal of this hash key is to detect any unauthorized changes to the user identity and prevent users from being used after an unauthorized change has been done. From an Oracle Utilities Application Framework point of view, an unauthorized change is a change that is done without going through the user object itself. For example, if you issued an UPDATE statement against the user tables directly, that did not go through the user object. That is an example of an unauthorized change.

When a user record is accessed, for example at login time, the Oracle Utilities Application Framework recalculates the hash key and compares that against the stored hash key. If they match, then the user is authorized, using the authorization model, to access the product. If the hash key does not match, then the user record has been compromised and the user action is rejected. In the case of a login, the user is refused access to the product.

The log will contain the message:

User security hash doesn't match for userid

From time to time we get customers reporting issues with these same characteristics. In most cases, this is caused by a number of practices:

• User Object Updated Directly. Some implementations update the user object via direct SQL for a particular reason. This technique is discouraged bypasses the business rules configured for the user object within the product. We recommend that customers update the user object via the provided methods to prevent the user becoming recognized as compromised. The user object is protected by the authentication and authorization model used.
• Encryption Key has been changed. At some sites, the encryption key is rotated on a regular basis. When this happens, the hash key becomes stale and needs to be rebuilt to reflect the new key.  

These are the only two use cases where the hash key becomes invalid. So what can be done about it? Well there are two techniques that are suggested to resolve this issue:

• Manually resolve the issue. The hash key is rebuilt upon update of the user object using the maintenance function (user interface or user object directly). Use an alternative valid authenticated and authorized user, to edit the invalid user object and saving the user object will regenerate the hash key. This is recommended for spot problems with low numbers of users. This technique is available, with configuration, in web services, plugin batch or request/request type processing if necessary.
• Synchronize Data Encryption Utility. The Oracle Utilities Application Framework provides a command line based utility to reset hash keys (and other encryption related information) on-masse. This utility is documented in the Security Guide supplied with your product in the section named Synchronize Data Encryption. It is recommended to use this utility to reset the user hashs when the problem is widespread. See also CCB and C2M V2.6.0.0.0 Demo Install Error User Security Hash Doesn't Match For Userid When Logging Into Environment (Doc Id 2270728.1), MDM 2.2 Hash Key Generation (Doc Id: 2359462.1) and 'resource [/loginError.jsp], because it is stale' Because User Security Hash Doesn't Match (Doc Id: 2054791.1) available from My Oracle Support.

Note: The utility will set all the hash's not just the invalid ones.

It is recommended not to alter the User Object directly without going through the user object to avoid security hash issues.

In the last Cube Viewer article we outlined a generic process for building a cube, but the first step on this process is to actually design the data we want to analyze in the cube. A common misconception with Cube Viewer is that you can take an query and convert it into a cube for analysis. This is not exactly true as Cube Viewer is really designed for particular types of analysis and should be used for those types of analysis to take full advantage of the capability.

The easiest way of deciding what type of analysis are optimal for the Cube Viewer is to visualize your end result. This is not a new technique as most designers work from what they want to determine the best approach. The easiest way I tend to visualize the Cube Viewer is to actually visualize the data in a more analytical view. If you are familiar with the "Pivot" functionality that is popular in spreadsheet programs then that is the idea. The pivot allows for different columns in a list to be combined in such a way to provide more analytical information. A very simple example is shown below:

The above example we have three columns, two are considered dimensions (how we "cut" the data) and one the value we want to analyze. The pivot relationship in the above example is between Column A and Column B.

In Cube Viewer there are three concepts:

• Dimensions. These are the columns used in the analysis. Typically dimensions represent the different ways you want to view the data in relation to other dimensions.
• Filters. These act on the master record set (the data you want to use in the analysis) to refine the subset to focus upon. For example, you might want to limit your analysis to specific date ranges. By their nature, Filters can also become dimensions in a cube.
• Values. These are the numeric values (including any functions) that need to analyzed.

Note: Filters and Values can be considered dimensions as well due to the interactivity allows in the Cube Viewer.

When designing your cube consider the following guidelines:

• Dimensions (including filters) define the data to analyze. The dimensions and filters are used to define the data to focus upon. The SQL will be designed around all the concepts.
• Interactively means analysis is fluid. Whilst dimensions, filters and values are defined in the cube definition, their roles can be altered at runtime through the interaction by the user of the cube. The user has interaction (within limits) to interactively define how the data is represented.
• Dimensions can be derived. It is possible to add ad-hoc dimensions that may or may not be even data in the database directly. The ConfigTools capability allows for additional columns to be added during the configuration that are not present directly in the SQL. For example, it is possible to pull in value from a related object not in the SQL but in the ConfigTools objects.

Note: For large amounts of data to include or process as part of the cube it is highly recommended to build that logic into the cube query itself to improve performance.

• Values need to be numeric. The value to be analyzed should be numeric to provide the ability to be analyzed correctly.

In he next series of articles we will explore actually building the SQL statement and then translating that into the ConfigTools objects to complete the Cube.

The Oracle Utilities Testing Accelerator is fast becoming a part of a lot of cloud and on-premise implementations as partners and customer recognize the value of pre-built assets in automated testing to reduce costs and risk. This growth necessitates a clarification in respect to licensing of the Oracle Utilities Testing Accelerator to ensure compliance with the license.

• Oracle Utilities product exclusive. The focus of the Oracle Utilities Testing Accelerator is to provide an optimized solution for optimizing testing of Oracle Utilities products. The Oracle Utilities Testing Accelerator is licensed for exclusive use with the Oracle Utilities products it is certified against. it will not work with product not certified as their is no content or capability inbuilt into the solution for product outside that realm.
• Named User Plus License. The Oracle Utilities Testing Accelerator uses the Named User Plus license metric. Refer to the License Definitions and Rules for a definition of the restrictions of that license. The license cannot be shared across physical users. The license gives each licensed user access to any relevant content available for any number of any supported non-production copies of certified Oracle Utilities products (including multiple certified products and multiple certified versions).
• Non-Production Use. The Oracle Utilities Testing Accelerator is licensed for use against non-Production copies of the certified products. It cannot be used against a Production environment.
• All components of the Oracle Utilities Testing Accelerator are covered by the license. The Oracle Utilities Testing Accelerator is provided in a number of components including the browser based Oracle Utilities Testing Workbench (including the execution engine), Oracle Utilities Testing Repository (storing assets and results of tests), Oracle Utilities Test Asset libraries provided by Oracle,  Oracle Utilities Testing Accelerator Eclipse Plug In and the Oracle Utilities Testing Accelerator Testing API implemented on the target copy of the Oracle Utilities product you are testing. These are subject to conditions of the license. For example, you cannot use the Oracle Utilities Testing Accelerator Testing API without the use of the Oracle Utilities Testing Accelerator. Therefore you cannot install the Testing API on a Production environment or even use the API in any respect other than with Oracle Utilities Testing Accelerator (and selected other Oracle testing products).

Oracle Utilities Testing Accelerator continues to be the cost effective way of reducing testing costs associated with Oracle Utilities products on-premise and on the Oracle Cloud.