X

Announcements and Technical Advice for the Oracle
Utilities product community from the Product Management team

  • February 16, 2020

UTA 6.0.0.2.0 Features - Flow Subroutines

Anthony Shorten
Senior Principal Product Manager

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.

Example 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:

New Test Flow

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

Flow Subroutines

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.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.