Anthony Shorten

Subscribe to Anthony Shorten feed
Oracle Blogs
Updated: 1 hour 8 min ago

Application Testing: The Oracle Utilities Difference

Wed, 2016-03-09 19:33

Late last year we introduced a new product to the Oracle Utilities product set. It was the Oracle Functional/Load Testing Advanced Pack for Oracle Utilities. This pack is a set of prebuilt content and utilities based upon Oracle Application Testing Suite.

One of the major challenges in any implementation, or upgrade, is the amount of time that testing takes in relation to the overall time to go live. Typically testing is on the critical path for most implementations and upgrades. Subsequently, customers have asked us to help address this for our products.

Typically one technique to reduce testing time is to implement automated testing as much as possible. The feedback we got from most implementations was that the adoption of automated testing tools initially was quite high as you needed to build and maintain the assets for the automated testing to be cost effective. This typically requires specialist skills in the testing tool.

This also brought up another issue with traditional automated testing techniques. Most traditional based automated testing tools use the user interface to record their automation scripts. Let me explain. Typically using traditional methods, the tool will "record" your interactions with the online system including the data you used. This is then built into a testing "script" to reproduce the interactions to automated them. This is limiting in that to use the same script with another set of data, for alternative sceanrios, you have to get a script developer to get involved and this requires additional skills. This is akin to programming.

Now let me explain the difference with Oracle Application Testing Suite in combination with the Oracle Functional/Load Testing Advanced Pack for Oracle Utilities:

  • Prebuilt Testing Assets - We provide a set of prebuilt component based assets that the product developers use to QA the product. These greatly reduce the need for building assets from scratch and get you testing earlier.
  • One pack, multiple products, multiple versions - The pack contains the components for the Oracle Utilities products supported and the versions supported.
  • Service based not UI based - The components in the pack are service based rather than using the UI approach traditionally used. This is to isolate your functionality from any user experience changes. In a traditional approach, any changes to the User Interface would require either to re-record the script or making programming changes to the script. This is not needed for the service based approach.
  • Supports Online, Web Services and Batch - Traditional approaches typically would cover online testing only. Oracle Application Testing Suite and the pack allows for online, web services and batch testing as well which greatly expands the benefits.
  • Component Generator Utility - Whilst the pack supplies the components you will need, we are aware the fact that some implementations are heavily customized so we provide a Component Generator which uses the product meta data to generate a custom component that can be added to the existing library.
  • Assemble not code - We use the Oracle Flow Builder product, used by many Oracle eBusiness Suite customers, to assemble the components into a flow that models your business processes. Oracle Flow Builder simply generates the script that is executed with the need for technical script development.
  • Upgrade easier - The upgrade process is much simpler with the flows simply pointed to the new version of the components supplied to perform your upgrade testing.
  • Can Co-exist with UI based Components - Whilst our solution is primarily service based, it is possible to use all the facilities in Oracle Application Testing Suite to build components, including traditional recording, to add any logic introduced on the browser client. The base product does not introduce business logic into the user interface so the base components are not user interface based. We do supply a number of UI based components in the Oracle Utilities Application Framework part of the pack to illustrate that UI based components can co-exist.
  • Cross product testing - It is possible to test across Oracle Utilities products within a single flow. As the license includes the relevant Oracle Application Testing Suite tools (Flow Builder, OpenScript etc) it is possible to add components for bespoke and other solutions, that are web or service based, in your implementation as well.
  • Flexible licensing - The licensing of the testing solution is very flexible. You not only get the pack and the Oracle Application Testing Suite but the license allows the following:
    • The license is regardless of the number of Oracle Utilities products you use. Obviously customers with more than one Oracle Utilities product we see a greater benefit but it is cost effective regardless.
    • The license is regardless of the number of copies of products you run the testing against. There is a server enablement that needs to be performed as part of the installation but you are not restricted to non-production copies you run the solution against.
    • The license conditions include full use of the Oracle Application Testing Suite for licensed users. This can be used against any web or Web Service based application on the site so that you can include third party integration as part of your flows if necessary.
    • The license conditions include OpenScript which allows technical people to build and maintain their own custom assets to add to the component libraries to perform a wide range of ancillary testing.
  • Data is separated from process - In the traditional approach you included the data as part of the test. Using this solution, the flow is built independent of the data. The data, in the form of databanks (CSV, MS Excel etc) can be attached at the completion of the flow, in the flow definition or altered AFTER the flow has been built. Even after the script has been built, Oracle Flow Builder separates the data from the flow so that you can substitute the data without the need to regenerate the script. This means you have greater reuse and greater flexibility in your testing.
  • Flexible execution of Testing - The Flow Builder product generates a script (that typically needs no alteration after generation). This script can be executed in OpenScript (for developers), using the optional Oracle Test Manager product, loaded into the optional Oracle Load Testing product for performance/load testing or executed by a third party tool via a command line interface. This flexibility means greater reuse of your testing assets. 
Support for Extensions

One of the most common questions I get about the pack is the support for customization (or extensions as we call them). Let me step back before answer and put extensions into categories.

When I discuss extending our product there is a full range of facilities available. To focus on the impact of extensions I am going to categorize these into three simple categories:

  • User Interface extensions - These are bits of code in CSS or Java script that extend the user interface directly or add business logic into the browser front end. These are NOT covered by the base components as the product has all the business logic in the services layer. The reason for this is that the same business rules can be reused regardless of the channel used (such as online, web services and batch). If you have it in just one channel then you miss those business rules elsewhere. To support these you can use the features of Oracle Application Testing Suite to record that logic and generate a component for you. You can then include that component in any flow, with other relevant components, to test that logic.
  • Tier 1 extensions - These are extensions that alter the structure of the underlying object. Anything that changes the API to the object are what I am talking about. Extension types such as custom schemas which alter the structure of the object (e.g. flattening data, changing tags, adding rules in the schema etc). These will require the use of the Component Generator as the API will be different than the base component.
  • Tier 2 extensions - These are extensions within the objects themselves that alter behavior. For example, algorithms, user exits, change handlers etc are example of such extensions. These are supported by the base components directly as they alter the base data not the structure. If you have a combination of Tier 1 and Tier 2 then you must use the Component Generator as the structure is altered.

Customers will use a combination of all three and in some cases will need to use the component generators (the UI one or the meta data one) but generally the components supplied will be reused for at least part of the testing, which saves time.

We are excited about this new product and we look forward to adding more technology and new features over the next few releases.

OSB 12c Adapter for Oracle Utilities

Tue, 2016-03-08 23:32

In Oracle Utilities Application Framework V4. we introduced  Oracle Service Bus adapters to allow that product to process Outbound Messages and for Oracle Utilities Customer Care And Billing, Notification and Workflow records.

These adapters were compatible with Oracle Service Bus 11g. We have not patched these adapters to be compatible with new facilities in Oracle Service Bus 12c. The following patches must be applied:

 Version  Patch Number  22308653  21760629  22308684  

Optimizing Your To Do Experience

Mon, 2016-03-07 17:52

One of the key objects in the Oracle Utilities Application Framework is the To Do object. It is one of the most commonly used objects and I am asked by customers and partners on various techniques they can use to manage the To Do records generated efficiently. Part of the issue with the To Do object is that it is sometimes used incorrectly causing implementation issues long term.

Before I outline some advice on how to optimize the use of To Do's I want to spend some time describing the concept of the To Do object.

Primarily the product is used to automate business processes within a utility organization (gas, electricity, water, waste water etc).  Sometimes, due to some condition or data issue, typically an exception, the product cannot automatically resolve the condition or data to satisfy the business process. In this case, a human needs to intervene to correct the condition or data and allow the process to proceed (usually on the next execution of the process). In this case the automation of the business process will create a To Do record outlining the type of exception (expressed in a To Do Type), the priority of the issue,  extra information, as well the links back to the relevant record that created the issue (for navigation). The product will allocate the To Do record to a To Do Role which presents the group of people that are allocated to address the exception. One of the people allocated to the To Do will work on the exception to resolve it and then mark the To Do as complete. The product will reprocess the original object that caused the exception whenever it is scheduled within the product.

In summary, whenever an exception is detected that requires human intervention, a To Do is created and then managed by designated individuals to resolve the exception for reprocessing. For example, say you are billing a customer and that customer has some information that is not complete for a successful bill to be generated. The product would raise a relevant To Do of a particular type and indicate a group of people to resolve the missing information so that the product can successfully bill that customer.

With all these facts in mind, here is my advice:

  • To Do's are transient. They should be treated as such. They are created as needed and then once they are completed they should be only retained for a short time and then removed. We supply a purge process, F1-TDPG, in the products to remove completed To Do's after a period of time. We also supply an ILM based solution for To Do's as well if you wish to retain the data for longer periods. There is an article outlining the purge process.
  • Do not use the To Do object for anything other than managing exceptions. I have seen it used to record business events and other data (including using it for a bespoke analytics). There are other methods for satisfying business requirements. For example, log entities can be used on most objects to record events and we also have a generic FACT object that can be used for all sorts of extensions.
  • Examine each To Do Type and see if someone in your organization is actually doing anything with those To Do entries. If there is no business process to deal with the exceptions then you should reexamine whether you need to actually generate the To Do in the first place. Having To Do entries sit there and not be closed is not recommended as it would just build up slowly. If you do not have a business process for the exception then consider turning off that To Do generation. You must do this for base To Do Types as well as any custom To Do Types.
  • For custom To Do Types, check for duplicate To Do entries. This does happen with customizations. When an exception occurs where a To Do needs to be generated, the customization should check if an existing To Do is already created before creating a new one.
  • Examine anywhere within the product where a To Do is created and completed within the same transaction. This is a sign that probably the To Do should not be created in the first place. Consider turning off the To Do creation. If this is needed for some business process, look at running the purge process regularly to keep these optimally.
  • Optimize the To Do Roles allocated to the To Do Type. The demonstration database is shipped with a single To Do Role per To Do Type. This is not the only configuration. You can use To Do roles to manage teams of people and then allocate them to the To Do Types they work on. You can have many To Do Types with many To Do Roles (and visa versa). You do need to nominate a default To Do Role on the To Do Type, which represents the default group of people to manage the To Do's of that To Do Type if no To Do Role is specified at creation time.
  • The To Do Type has a number of algorithms that allow for greater control of the To Do:
    • Calculate Priority - By default the priority on the To Do record is inherited from the To Do Type but it is possible to alter the Priority based upon additional information in the object or in your processing using this algorithm.
    • External Routing - Routing To Do information to external systems or other objects.
    • To Do Post Processing - Process the To Do after it is created or updated. For example, if the To Do is updated you can use this algorithm to pass additional information or state to another system or dashboard application.

These are some of the techniques that will optimize your experiences with To Do. Remember the volume of To Do's is really an indicator of your data quality so improving the quality of data is also a valid technique for minimizing the management of To Do.

There is additional advice on optimal managing of To Do in the whitepaper Overview and Guidelines for Managing Business Exceptions and Errors (Doc Id: 1628358.1) from My Oracle Support.

Cloud and not to Cloud

Fri, 2016-03-04 12:21

At the Oracle Utilities Edge Conference the word most said was "Cloud" and whilst I tried to avoid overusing the word in my sessions I think it is important to clarify and understand what this means to your implementation.

  • We announced our Software As A Service plans and capabilities at the Oracle Utilities Edge Conference. This is a full service offering from us.
  • We announced our support for Platform As A Service (a whitepaper will be out in a few weeks time on this) and support for Private Clouds.
  • We announced a series of capabilities across deploying, extending and managing our cloud implementations available now, soon and in the future.

Even if you are not intending to use ANY cloud facilities now and in the future there are some key messages to remember:

  • EVERYTHING, that is applicable, we are introducing to make or cloud implementation easier and more efficient will be rolled into the products (either into the product or the Oracle Application Management Pack for Oracle Utilities) available for on-premise and Private Cloud implementations. This is a key thing to remember. Just because we are focusing some of our efforts on the cloud, we are not abandoning other implementation styles. Anything we make easier will make your implementations much easier.
  • We are not assuming all customers will use the cloud so we are offering flexible cloud offerings to cover as much of the spectrum as we can. For example, you can use PaaS for your non-production environments and retaining on-premise for production. This gives you full access as you would see on site with some of the cost moved away.
  • We are in fact duplicating some of our functionality for on-premise and cloud implementations. For example, I announced that all the cloud metrics we are exposing to the cloud will also be available in our Application Management Pack for Oracle Utilities as well for on-premise implementations. This is just an example of trying to give you what we use. Our Oracle Functional/Load Testing Advanced Pack for Oracle Utilities is another example. It contains the testing components we use in our QA cycles.


Extending the Product - Supporting technologies

Fri, 2016-03-04 12:05

First of all I want to thank all the customers and partners who attended the technical stream at the annual Oracle Utilities Edge Conference in Phoenix Arizona. I hope those attended found the sessions helpful. It was a pleasure to meet and chat to many customers and partners during and after the sessions.

We made a series of announcements at the sessions about the future directions of our products and our works program for the future. Customers and Partners who did not attend the conference will get this information as we publically release the facilities we discussed over the next few service packs and releases.

One of the announcements has caused confusion amongst the attendees and I wanted to clarify a few points to make sure that everyone understands the announcement.

We announced that we will be adding support for Groovy as an extension language in a future release. I want to point out a few things about this:

  • Groovy support for extensions was added primarily to support our Software As A Service (SaaS) offerings for our products. In SaaS we will lock down the facilities accessible for extensions to protect security and performance. As Java has access low level calls we will not allow Java based extensions in the SaaS cloud. As Groovy is used for a similar role in other Oracle Cloud offerings, we are extending the OUAF to support Groovy based extensions to allow extensions typically implemented in java to be implemented in the cloud. We will be supporting Scripting and Groovy based extensions in SaaS offerings.
  • To protect security and performance we will be whitelisting support upon parts of Groovy to prevent inappropriate access. We use a similar technique for scripting and other extension support.
  • Java and scripting based extension support will be continued to be supported in the OUAF. You will not be forced to migrate to Groovy for on-premise, Platform As A Service (PaaS) and Private Cloud implementations. We will continue to extend our Java, Groovy and scripting support over future releases. We are not dropping the existing technologies. 
  • You can use Groovy for on-premise, Platform As A Service (PaaS) and Private Cloud implementations if you desire to use that technology. Java programmers can migrate to Groovy skills pretty easily as Groovy is very similar to Java (at the end of the day Groovy code becomes Java byte code anyway).

In summary, Groovy is being supported as an alternative to scripting and Java, it is not replacing them. It is primarily used to address the lack of access to Java for use in building extensions in Oracle Utilities SaaS offerings. It can be used by any style of implementation if you desire but if you are not using our SaaS offerings you can continue to use all the styles of extension we have available.

Now that I clarified that, I want to clarify one other misconception and that is the performance profile of the different styles:

  • When loaded into memory, which what happens to all extensions regardless of technology, raw performance of Java, scripting and Groovy are similar. Java does have a slight edge as it compiled byte code and Groovy/Scripting are interpreted with a small initial overhead. There is not much difference in the performance once it ends up in memory. You have the flexibility of picking any of those technologies with confidence that the code will perform with efficient programming.
  • Each language has its facilities and there are some clauses that are unique to each. For example, Java has full flexibility especially with computational type and also has a wide API. Groovy has a very similar API to Java but in our implementation of Groovy, we will be whitelisting clauses to protect security and performance. Scripting has a generous set of programming clauses but it is smaller in scope. In the vast majority of most extensions, scripting is more than enough but you can choose to use Java or Groovy (in the future). The choice if language gets down to skills and what your scope is.
  • In most case it is recommended to use scripting first, if that is not appropriate then you can soon use Groovy and even if that is not appropriate then use Java. Java has overheads in deployment where scripting and Groovy will be stored in our metadata.

I hope these clarifications will assist you in extending our products now and in the future. We are looking forward to providing a rich development experience no matter which style or technique you choose to use.


Running To Do Purge regularly, improves your performance

Mon, 2016-02-22 16:44

One of the most common issues in implementations of Oracle Utilities Application Framework based products is the growth of To Do object.

The To Do object is to catch errors or events that need human intervention and cannot be addressed by the logic in the product. Basically something has to be done by someone to correct something as part of the process.

The To Do goes through various states and ends up Completed in its final state. There may be a few steps in between but eventually all To Do's should end up in a Completed state. Now when a To Do is in a completed state, the work associated is essentially completed so the retention of that To Do is a s long as your business wants to retain that data.

In terms of management there are a number of techniques that can be used to decide what to do with Completed To Do's:

  • You can use the ILM solution provided with most of the products to retain the To Do as long as your business requires to refer back to it.
  • You can use the To Do Purge batch job (F1-TDPG) to remove Completed To Do's. This job can be used globally or by To Do Type. This is the most common approach.

If you use the To Do Purge job then there are a few guidelines to optimize its use:

  • If there are a large number of completed To Do's to purge initially, then consider setting the noOfDays to a chunk of To Do's to efficiently to remove them.
  • You can set the scope of the job with a combination of isDeleteAll, deletedToDoTypes and excludedToDoTypes. This allows you to set different retention rates for each To Do Type.
  • You can copy the Batch control to implement different job conditions.
  • Schedule the purge jobs regularly to maintain a healthy balance between retention and storage costs.

Maintaining the To Do table has an impact on almost any part of the product as it is used by almost every process (directly or indirectly).

2016 Oracle Utilities America’s Product Development Customer Advisory Board

Thu, 2016-01-07 22:49

I will be attending the 2016 Oracle Utilities America’s Product Development Customer Advisory Board this year which is in Phoenix Arizona from the Feb 29th till 3rd March. This year we are running a dedicated technical stream highlighting specific technical features and also running a Technical Q&A Panel to answer technical questions and discuss our directions.

The sessions will be focused on technical aspects of the solution and be a combination of presentations on topics, live demonstrations and question/answer sessions with product experts. The planned sessions this year are:

 Session  Overview  Security Features and Functions
In this session the new and improved security features of the Oracle Utilities Application Framework will be discussed including integrations to various security technologies to understand and take advantage of the advanced security solutions now available.
 Web Services Integration
In this session the new Inbound Web Services, Message Driven beans and REST functionality of the Oracle Utilities Application Framework are highlighted to understand the integration capabilities for implementation. This session will include integrations to SOA products.
 Information Lifecycle Management
In this session the new Information Lifecycle Management solution will be outlined and discussed to highlight the capabilities, implementation strategies and techniques for reducing storage costs whilst retaining data for business purposes
 Managing your Utilities environment using Oracle Enterprise Manager In this session the techniques and capabilities of reducing your IT management costs using Oracle Enterprise Manager are outlined including using the base capabilities of the console and using the various packs available to augment the solution including the Oracle Application Management Pack for Oracle Utilities.
 Technical Cloud Solutions
In this session the technical architecture of Oracle Cloud offerings for Software As A Service (SaaS) and Platform As A Service (PaaS) will be discussed. This session highlights all the technology used in the solution as well as the architecture of those solutions.
 Oracle Utilities Framework Roadmap
In this session the roadmap of the Oracle Utilities Application Framework will be outlined.
 Oracle Utilities Testing Solutions
In this session the new Oracle Application Testing Suite based testing accelerators for Oracle Utilities products will be outlined and demonstrated for quick adoption of automated testing. The solution includes Functional/Regression Testing, Performance/Load Testing and Testing Management.
 Mobile Framework Overview
In this session the planned Mobile Server integration architecture and technology will be highlighted to allow connected and disconnected mobile clients for Oracle Utilities products.
 Technology Strategy
In this session the short, medium and long term technology strategy will be discussed to outline the technology directions and integrations for the Oracle Utilities Application Framework in future releases. There will be a Q&A session in this session as well to discuss technology options.
 Technical Implementation Q&A Panel
This session will be generic panel session where product managers and product developers are available for customer and partner questions and discussions on technical aspects of implementations.

I will be available for all these sessions with other product managers and will also be attending the Customer User Group meetings after the CAB has completed. These sessions are designed for technical personnel rather than business personnel.

I look forward to seeing you at the CAB. For those in APAC, I am also attending the APAC CAB in Melbourne (my home town) in Mid February 2016 with a subset of these sessions.

Oracle Application Management Pack for Oracle Utilities available

Sun, 2016-01-03 21:27

We are pleased to announce that a new version of the Oracle Application Management Pack for Oracle Utilities has been released to support the new release of Oracle Enterprise Manager 13c. We are excited to offer this new pack which now supports the new features of Oracle Enterprise Manager including:

  • The user interface has been updated to reflect the new Alta look and feel implemented by Oracle Enterprise Manager
  • The Always On feature is now supported that is used by Oracle Enterprise Manager to drastically reduce downtime for Oracle Enterprise Manager or pack maintenance
  • The System Broadcast feature is now supported allowing broadcast across all Oracle Enterprise Manager users
  • Support for Brownouts is now included where non-scheduled outages are now calculated separately for Service Level Agreement checking
  • and many more...

The functionality of the pack is the same as the latest release of the pack for Oracle Enterprise 12c for backward compatibility reasons. This pack requires Oracle Enterprise Manager 13c. The new version of the pack is available from Self Update within Oracle Enterprise Manager 13c and Oracle Software Delivery Cloud.

A new release of the pack is also scheduled in the near future with additional functionality to fully exploit additional new and exciting features of Oracle Enterprise Manager 13c. For more information about Oracle Enterprise Manager 13c refer to the EM blog post.

Product vs Solution vs Infrastructure

Sun, 2016-01-03 20:29

One of the most common questions I get from partners is support for features that are typically in the infrastructure. The main issue here is that some partners confuse what is in the product and what is in the infrastructure and the implementation solution. Let me explain.

The Oracle Utilities Application Framework based products are applications housed within J2EE infrastructure (such as Oracle WebLogic and in some cases IBM WebSphere) and for batch, housed in a runtime version of Oracle Coherence.

Now there is a degree of separation between the product and the infrastructure. Each has distinct roles and those roles are only duplicated across what we call touchpoints between the product and the infrastructure. Another complication comes into play is the role of the solution which the particular configuration of the product and the infrastructure to suit a particular need.

When I was considering writing this article to highlight the differences in product, infrastructure and solutions I bounced around a few ways of describing it but I found the nest way is in the form of a common example.

Lets use the example of security authentication (aka who are you?). This is essentially the feature of securing and identifying the user when connecting to the product. The most common example of this is known as challenge and response (or more commonly userid and password).

In terms of the roles security authentication is described as follows in terms of product, infrastructure and solution:

  • The product does not store userid and password itself. It does not make sense in the context of an enterprise application as typically security is enterprise wide, for efficiency reasons, not just for a particular product. This is delegated to the J2EE container (Oracle WebLogic/IBM WebSphere) to authenticate the user. The product relies on the container to pass or fail an authentication attempt.
  • The J2EE container, which is part of the infrastructure, supports various security repositories and standards via security connectors. For example, if you have a corporate security server that holds users and passwords then you can connect it via LDAP to the container to now implement a common identity store. The J2EE container supports a wide range of adapters and in the case of Oracle WebLogic you can implement multiples for different parts of your business. An example of this is where you can separate administration accounts from common users using different identity stores.
  • A solution for the product is a distinct configuration of the J2EE container with appropriately configured security connectors. This can also mean that you externalize this function even further by implementing an Identity Management solution such as Oracle Identity Management Suite.

As you see in the example, there are distinct differences between the product, solution and infrastructure. You can apply the same logic to a wide range of implementation aspects needed to be considered.

Now, lets focus on a particular issue using the example above. Where should the users be able to change their password?

  • The product does not have inbuilt password change functionality. This is because in a solution context, it makes no sense. This is why we do not supply one. It does not mean you cannot add this functionality to the menu as a common function.
  • The product is always connected to a security repository via the J2EE container (even the default one shipped with the J2EE container). The password change function is at the infrastructure level not the product level.
  • Typically you can change passwords from external sources which is much more logical. Lets take the common example of reusing the same security repository for LAN login and the product (via a common LDAP source with or without SSO). If you use this example, typically the LAN login allows you to change your password which would apply to all connected applications. It makes no sense in this example to also duplicate the functionality in the product. Also why would you let the product change a security repository.

The above example brings the discussion into sharp focus.

Now, how do I deal with these situations? I call it "What would product <blank> do in this situation?", where <blank> is your favorite desktop application. I usually use Office as an example (not a great example but something most people understand). You would not expect Word or its equivalent to have a password maintenance function. No, it does not make sense. Word in this example, uses the features of the operating system to do all sorts of functions like printing, scanning etc... The application does not have all these functions inbuilt (otherwise it would not be a word processor really).

Hope this clarifies the situation.

WS-Policy Support for IWS

Sun, 2015-12-20 20:43

One of the major advantages of Inbound Web Services (IWS) is the support for security based around the WS-Policy standard. By supporting WS-Policy it is now possible to support a wide range of transport and message security standards within each individual web service. It is also possible to support multiple policies. This allows maximum flexibility for interfacing to Oracle Utilities products using the WS-Policy support provided by Oracle WebLogic and IBM WebSphere (for selected products).This means the Web Services client calling our Inbound Web Services must comply with at least one of the WS-Policy directives attached to the service.

The support for WS-Policy is implemented in a number of areas:

  • It is possible to attach custom WS-Policy compliant policies directly to the Inbound Web Service as an annotation. The Oracle Utilities product supplies an optional default annotation to implement backward compatibility with XML Application Integration (XAI). This allows customers using XAI to more for Inbound Web Services. Oracle recommends not to attach policies within the Inbound Web Services definition as that can reduce the flexibility of your interfaces.
  • It is possible to attach policies within the J2EE Web Application service AFTER deployment to individual web services. This information is retained across deployments using a deployment file that is generated by the container at deployment time. In Oracle WebLogic this is contained in the deployment plan generated by the deployment activity, it will  reapply the policies during each redeployment process automatically. For Oracle WebLogic, a large number of WS-Policy files are supported for message and transport.
  • For Oracle WebLogic EE customers, it is possible to also use Oracle Web Services Manager to attach additional WS-Policy security policies supported by that product. Again this is done by deployment time. The advantage of Oracle Web Services Manager is that it reuses all of the policies supplied with Oracle WebLogic, adds advanced policies and also adds access control functionality rules you can attach to an Inbound Web Service to control when, who and where it is used.

The bottom line is that you can use any policy (supplied with the J2EE container or custom) that is supported by the J2EE container. You cannot introduce a policy that is not compatible with the container itself as we delegate security to the container.

The only thing we do not support at the present is applying a WS-Policy to part of a message or at the operation level. The WS-Policy is applies across the web service.

Optimizing Log levels in OUAF based applications

Mon, 2015-12-07 22:22

Typically the default setup of logging in Oracle Utilities Application Framework based application favors non-production environments. This can cause excessive logging in specific situations in the various channels available.

The Oracle Utilities Application Framework uses log4j for log management. The (default name) controls the individual channels logging information and level. The names and locations of the files are discussed in the Server Administration Guides shipped with the products.

The setting can be altered to suit the amount of logging. The following values are supported (in order of least to most logging):

  • off - The OFF has the highest possible rank and is intended to turn off logging. This is not recommended.
  • fatal - The FATAL level designates very severe error events that will presumably lead the application to abort.
  • error - The ERROR level designates error events that might still allow the application to continue running.
  • warn- The WARN level designates potentially harmful situations.
  • info - The INFO level designates informational messages that highlight the progress of the application at coarse-grained level.
  • debug - The DEBUG Level designates fine-grained informational events that are most useful to debug an application.
  • all - The ALL has the lowest possible rank and is intended to turn on all logging. Only recommended for development environments for use with developers.

Each level includes the levels above. For example a setting of info would include messages of type fatal, error, warning as well as info.

The format of the settings typically look like this:

Each configuration file has multiple logging settings to cover the logging types of individual elements of the architecture. You can optimize individual components of the architecture within a channel.

To implement this you will need to use custom templates as the templates are prebuilt. Refer to the Server Administration Guide supplied with your version of the product for instructions on how to build and use custom templates.

Warning: Changing log levels can hide messages that you might find helpful. Just be careful when setting custom levels.

The Oracle Flow Builder difference

Wed, 2015-12-02 20:15

One of the key features of the Oracle Functional/Load Testing Advanced Pack for Oracle Utilities is the support for Oracle Flow Builder. Those not familiar with this product. It is a component and flow management tool to quickly build and maintain testing assets with reduced skills required.

Oracle Flow Builder is not a new product to Oracle. Previously it was exclusively part of the successful product Oracle eBusiness Suite. It was developed to automate the testing of that product to reduce time to market and reduce the risk in implementation and upgrades. It was developed for internal quality assurance originally but we released to success to Oracle eBusiness Suite customers. Customer and QA teams reported up to 70% saving on testing time.

Keen to realize these savings across other products, Oracle moved the Oracle Flow Builder product to be part of the functional testing part of the Oracle Application Testing Suite. This is where our pack came into existence. We had the components available but originally no way to allow customers to quickly adopt the components into flows. It is possible in OpenScript to code a set of component calls, this required higher levels of skills, but quickly it was apparent that Oracle Flow Builder was the solution.

The two development teams worked closely together to allow the pack to be the first product set outside of Oracle eBusiness Suite to support Oracle Flow Builder. This relationship offers great advantages for the solution:

  • Oracle Flow Builder allows non-development resources to build and maintain components and testing flows.
  • Oracle Flow Builder includes a component management toolset to manage the availability and use of components for testing.
  • Oracle Flow Builder including a flow management toolset to allow testers to orchestrate components into testing flows representing different scenarios of business flows. This allows modelling of business flows much easier.
  • Oracle Flow Builder is a team based solution running on a server rather than individual desktops. Typically testing tools, even OpenScript, run on individual desktops which means team development is much harder.
  • Oracle Flow Builder is tightly integrated with Oracle's other testing products in the Oracle Application Testing Suite family to implement testing planning, testing automation and load testing.

Oracle Flow Builder is a key part of our testing infrastructure and it is also a key part for the testing solution for Oracle Utilities products.

For training on Oracle Flow Builder you can use the Youtube Oracle Learning Library training or use the Oracle Learning Library training.

Oracle Functional/Load Testing Advanced Pack for Oracle Utilities Released

Wed, 2015-12-02 17:28

A new version of the Oracle Functional/Load Testing Advanced Pack for Oracle Utilities is now available for download from Oracle Software Delivery Cloud.

Look for Oracle Functional Testing Advanced Pack for Oracle Utilities, looking for Version, as this download includes support for Functional and Load testing.

This new version of the pack now supports a bigger range of Oracle Utilities products and a bigger range of versions. It also includes a component generator and component verifier to allow implementations to build custom components quickly from the meta data.

This new version of the pack supports the following releases:

  • Oracle Utilities Customer Care And Billing (new)
  • Oracle Utilities Customer Care And Billing
  • Oracle Utilities Mobile Workforce Management (updated)
  • Oracle Real Time Scheduler (updated)
  • Oracle Utilities Application Framework (new)
  • Oracle Utilities Application Framework
  • Oracle Utilities Meter Data Management (new)
  • Oracle Utilities Smart Grid Gateway (all adapters) (new)
  • Oracle Utilities Work And Asset Management 2.1.1 (updated)
  • Oracle Utilities Operational Device Management 2.1.1 (new)

The pack is content for Oracle Application Testing Suite for Functional Testing and Load Testing.

Channel Based Architectures

Tue, 2015-12-01 22:43

Over the last few releases of the Oracle Utilities Application Framework, architecture changes have been introduced to move towards a more channel based architectures. The idea is that a channel is an interface method that allows access to the product. One of the key principles is to divide the traffic interfaces into different channels to allow for those channels to be sized, managed and secured using different methods optimized for that channel.

In the Oracle Utilities Application Framework we have implemented the following channels:

  • Online Server - This is the Web based interface that allows online users access to the OLTP functionality of the product.
  • Integration Server - This is a web service based interface supporting SOAP, MDB, SOA, REST etc to allow interfaces to integrate to the product.
  • Batch Server - This is a command Oracle Coherence based channel to support background or batch processing.
  • Mobile Server (New) - This is a new channel we have started to introduce to progressive products to support a connected and disconnected mobile solution.

This channel based architecture is designed with the following principles:

  • Each channel can be installed separately or as a composite installation. In the latest version of the Oracle Utilities Application Framework we introduced the idea of an installation role. When you install the product you decide its role (or roles) which enables a channel for that installation. The role can be decided at installation time but can be changed, for flexibility, after installation without the need for re-installation. This also allows for what we call disparate installations which are installations across many hosts (for availability/scalability). We introduced an environment identifier which allows products like Oracle Enterprise Manager to recognize virtual disparate installations.
  • Each channel can be deployed individually. This allows for flexibility in implementing Oracle's Maximum Availability Architecture based solutions to support high levels of availability and scalability. This means the channel can be clustered individually or implemented in component clusters as well (depending on your preferences).
  • Each channel can be secured appropriately using the technology available to you. This essentially means you can use the facilities in the J2EE Web Application Server and associated security products to secure each channel appropriately. For example, the Integration Server which is Web Services based can be secured additionally with Oracle Web Services Manager and the policies supported by the Oracle WebLogic Server. We support the security connectors that Oracle supplies for its servers and also the advanced security offered by other Oracle Security products such as Oracle Identity Management Suite.
  • Each channel can be sized and ring fenced using features like Database Resource Manager and Oracle WebLogic Work Managers. This allows each channel to be controlled at the architectural level to isolate and preserve capacity. This is important in cloud implementations for example to ensure that capacity is maintained. This also allows flexibility in processing capacity with rules for allocating capacity able to be specified at the channel level or lower.
  • Oracle Enterprise Manager and the Application Management Pack for Oracle Utilities have been updated to reflect this new architecture to allow you to track and monitor appropriate metrics for the channel.

Over the next few releases, additional facilities will be included to enhance and reinforce the channel based architecture we have implemented. We feel that it will make implementations easier to plan and software easier to manage in the long term.

Database Resource Plan Support

Tue, 2015-12-01 16:59

Database resource plans in the database allow users and sessions limits to be managed to allow for finite control of resource usage on machines. They allow database administrators to set resource limits and configure resource sharing so that transactions, users and channels can have appropriate access to finite resources on the machine.

For Oracle Utilities products it is now possible to use database resource plans to control resources. The support varies with each version of Oracle Utilities Application Framework but the use cases you can use this for are as follows:

  • In Oracle Utilities Application Framework V4.x we introduced a different database user for each channel (online, web services and batch). These can be used in the database resource plan definition to control resources at a user level. In older versions of Oracle Utilities Application Framework (V2.x) we supply common users but it was possible, using templates, to implement separate users for at least online and batch so Database Resource Plans can be implemented there as well. This means that you can setup plans at the user level to control resources if necessary.
  • In all versions of Oracle Utilities Application Framework we have a separate Read-Only user. This is used typically for reporting tools. You can attach resource plans to this user to limit the resources used by reporting tools (for example, CPU and time limits).
  • In Oracle Utilities Application Framework V4.x we introduced additional session values to display module, action, client_identifier and client_info for active sessions. It is possible to also use these values to setup advanced resource plans if desired.

Setting up database resource plans is done at the database level using database tools such as SQL*Plus, SQL Developer, EM Express or Oracle Enterprise Manager. A whitepaper has been written to explain the facility as well as a example plan which is available from My Oracle Support at Using the Database Resource Manager to Manage Database Server Resources (Doc ID 2067783.1).

Whitepaper List as at November 2015

Thu, 2015-11-05 16:55
The following Oracle Utilities Application Framework technical whitepapers are available from My Oracle Support at the Doc Id's mentioned below. Some have been updated in the last few months to reflect new advice and new features.

Unless otherwise marked the technical whitepapers in the table below are applicable for the following products (with versions):

Doc Id Document Title Contents ConfigLab Design Guidelines This whitepaper outlines how to design and implement a data management solution using the ConfigLab facility.
This whitepaper currently only applies to the following products:
Technical Best Practices for Oracle Utilities Application Framework Based Products Whitepaper summarizing common technical best practices used by partners, implementation teams and customers. Performance Troubleshooting Guideline Series A set of whitepapers on tracking performance at each tier in the framework. The individual whitepapers are as follows:
  • Concepts - General Concepts and Performance Troublehooting processes
  • Client Troubleshooting - General troubleshooting of the browser client with common issues and resolutions.
  • Network Troubleshooting - General troubleshooting of the network with common issues and resolutions.
  • Web Application Server Troubleshooting - General troubleshooting of the Web Application Server with common issues and resolutions.
  • Server Troubleshooting - General troubleshooting of the Operating system with common issues and resolutions.
  • Database Troubleshooting - General troubleshooting of the database with common issues and resolutions.
  • Batch Troubleshooting - General troubleshooting of the background processing component of the product with common issues and resolutions.
Software Configuration Management Series
A set of whitepapers on how to manage customization (code and data) using the tools provided with the framework. Topics include Revision Control, SDK Migration/Utilities, Bundling and Configuration Migration Assistant. The individual whitepapers are as follows:
  • Concepts - General concepts and introduction.
  • Environment Management - Principles and techniques for creating and managing environments.
  • Version Management - Integration of Version control and version management of configuration items.
  • Release Management - Packaging configuration items into a release.
  • Distribution - Distribution and installation of releases across environments
  • Change Management - Generic change management processes for product implementations.
  • Status Accounting - Status reporting techniques using product facilities.
  • Defect Management - Generic defect management processes for product implementations.
  • Implementing Single Fixes - Discussion on the single fix architecture and how to use it in an implementation.
  • Implementing Service Packs - Discussion on the service packs and how to use them in an implementation.
  • Implementing Upgrades - Discussion on the the upgrade process and common techniques for minimizing the impact of upgrades.
Oracle Utilities Application Framework Security Overview A whitepaper summarizing the security facilities in the framework. Now includes references to other Oracle security products supported. LDAP Integration for Oracle Utilities Application Framework based products A generic whitepaper summarizing how to integrate an external LDAP based security repository with the framework. Oracle Utilities Application Framework Integration Overview A whitepaper summarizing all the various common integration techniques used with the product (with case studies). Single Sign On Integration for Oracle Utilities Application Framework based products A whitepaper outlining a generic process for integrating an SSO product with the framework. Oracle Utilities Application Framework Architecture Guidelines This whitepaper outlines the different variations of architecture that can be considered. Each variation will include advice on configuration and other considerations. Batch Best Practices This whitepaper outlines the common and best practices implemented by sites all over the world. Technical Best Practices V1 Addendum Addendum to Technical Best Practices for Oracle Utilities Customer Care And Billing V1.x only. XAI Best Practices This whitepaper outlines the common integration tasks and best practices for the Web Services Integration provided by the Oracle Utilities Application Framework. Oracle Identity Manager Integration Overview This whitepaper outlines the principals of the prebuilt intergration between Oracle Utilities Application Framework Based Products and Oracle Identity Manager used to provision user and user group security information. For Fw4.x customers use whitepaper 1375600.1 instead. Production Environment Configuration Guidelines A whitepaper outlining common production level settings for the products based upon benchmarks and customer feedback. 1177265.1 What's New In Oracle Utilities Application Framework V4?  Whitepaper outlining the major changes to the framework since Oracle Utilities Application Framework V2.2. 1290700.1 Database Vault Integration Whitepaper outlining the Database Vault Integration solution provided with Oracle Utilities Application Framework V4.1.0 and above. 1299732.1 BI Publisher Guidelines for Oracle Utilities Application Framework Whitepaper outlining the interface between BI Publisher and the Oracle Utilities Application Framework 1308161.1 Oracle SOA Suite Integration with Oracle Utilities Application Framework based products This whitepaper outlines common design patterns and guidelines for using Oracle SOA Suite with Oracle Utilities Application Framework based products. 1308165.1 MPL Best Practices
This is a guidelines whitepaper for products shipping with the Multi-Purpose Listener.
This whitepaper currently only applies to the following products:
1308181.1 Oracle WebLogic JMS Integration with the Oracle Utilities Application Framework This whitepaper covers the native integration between Oracle WebLogic JMS with Oracle Utilities Application Framework using the new Message Driven Bean functionality and real time JMS adapters. 1334558.1 Oracle WebLogic Clustering for Oracle Utilities Application Framework This whitepaper covers process for implementing clustering using Oracle WebLogic for Oracle Utilities Application Framework based products. 1359369.1 IBM WebSphere Clustering for Oracle Utilities Application Framework This whitepaper covers process for implementing clustering using IBM WebSphere for Oracle Utilities Application Framework based products 1375600.1 Oracle Identity Management Suite Integration with the Oracle Utilities Application Framework This whitepaper covers the integration between Oracle Utilities Application Framework and Oracle Identity Management Suite components such as Oracle Identity Manager, Oracle Access Manager, Oracle Adaptive Access Manager, Oracle Internet Directory and Oracle Virtual Directory. 1375615.1 Advanced Security for the Oracle Utilities Application Framework This whitepaper covers common security requirements and how to meet those requirements using Oracle Utilities Application Framework native security facilities, security provided with the J2EE Web Application and/or facilities available in Oracle Identity Management Suite. 1486886.1 Implementing Oracle Exadata with Oracle Utilities Customer Care and Billing This whitepaper covers some advice when implementing Oracle ExaData for Oracle Utilities Customer Care And Billing. 878212.1 Oracle Utilities Application FW Available Service Packs This entry outlines ALL the service packs available for the Oracle Utilities Application Framework. 1454143.1 Certification Matrix for Oracle Utilities Products This entry outlines the software certifications for all the Oracle Utilities products. 1474435.1 Oracle Application Management Pack for Oracle Utilities Overview This whitepaper covers the Oracle Application Management Pack for Oracle Utilities. This is a pack for Oracle Enterprise Manager. 1506830.1 Configuration Migration Assistant Overview
This whitepaper covers the Configuration Migration Assistant available for Oracle Utilities Application Framework V4. This replaces ConfigLab for some products.
1506855.1 Integration Reference Solutions
This whitepaper covers the various Oracle technologies you can use with the Oracle Utilities Application Framework. 1544969.1 Native Installation Oracle Utilities Application Framework This whitepaper describes the process of installing Oracle Utilities Application Framework based products natively within Oracle WebLogic. 1558279.1 Oracle Service Bus Integration  This whitepaper describes direct integration with Oracle Service Bus including the new Oracle Service Bus protocol adapters available. Customers using the MPL should read this whitepaper as the Oracle Service Bus replaces MPL in the future and this whitepaper outlines how to manually migrate your MPL configuration into Oracle Service Bus.

Note: In Oracle Utilities Application Framework V4. and above, Oracle Service Bus Adapters for Outbound Messages and Notification/Workflow are available 1561930.1 Using Oracle Text for Fuzzy Searching This whitepaper describes how to use the Name Matching and  fuzzy operator facilities in Oracle Text to implemement fuzzy searching using the @fuzzy helper fucntion available in Oracle Utilities Application Framework V4. 1606764.1
Audit Vault Integration This whitepaper describes the integration with Oracle Audit Vault to centralize and separate Audit information from OUAF products. Audit Vault integration is available in OUAF and above only.
Migrating XAI to IWS
Migration from XML Application Integration to the new native Inbound Web Services in Oracle Utilities Application Framework and above.
Private Cloud Planning Guide
Planning Guide for implementing Oracle Utilities products on Private Clouds using Oracle's Cloud Foundation set of products.
ILM Planning Guide
Planning Guide for Oracle Utilities new ILM based data management and archiving solution.
ILM Implementation Guide for Oracle Utilities Customer Care and Billing
Implementation Guide for the ILM based solution for the Oracle Utilities Customer Care And Billing.
Client / Server Interoperability Support Matrix
Certification Matrix.
Cache Nodes Configuration using BatchEdit utility
Using the new Batch Edit Wizard to configure batch quickly and easily
Overview and Guidelines for Managing Business Exceptions and Errors
Best Practices for To Do Management
Oracle Functional/Load Testing Advanced Pack for Oracle Utilities Overview
Overview of the new Oracle Utilities testing solution. Updated for
ConfigTools Best Practices
Best Practices for using the configuration tools facility
Oracle Utilities Application Framework - Keystore Configuration
Managing the keystore

Oracle Utilities on Oracle Technology Network

Thu, 2015-11-05 15:45

Information about the Oracle Utilities solutions is now available from the Oracle Technology Network.

This site includes links to download software, find documentation, connect to the user community and learn more about our solutions.

Flow Builder/OpenScript and Oracle Test Manager

Wed, 2015-11-04 19:32

The Oracle Functional Testing Advanced Pack for Oracle Utilities provides the content to use Oracle Application Testing Suite to verify your business processes via flows using your test data for multiple scenarios.

Customers have asked the relationship with the tools in the Oracle Application Testing Suite. Here is the clarification:

  • The Oracle Functional Testing Advanced Pack for Oracle Utilities is loaded into the Oracle Flow Builder component of the Oracle Application Testing Suite Functional Testing product. The components represent all the functions within the product.
  • You build a flow, using drag and drop, sequencing the provided components that matches the business process you want to verify. If there is no component we ship that covers your extensions then you can use a supplied component builder to build a meta data based service component. If you want to model a user interface then OpenScript can be used to record a component to add to the component library.
  • You then can attach your test data. There are a number of techniques available for that. You can natively input the data if you wish into the component, generate a spreadsheet to fill in the data (and attach it after you filled it out) or supply a CSV data file that represents the data in the flow.
  • You generate (not code) a script. No additional coding is required. As part of the license you can code OpenScript if  you have developers for any work if you wish but it is typically not required.
  • You then have a choice to execute the script.
    • You can execute the script from the OpenScript tool in Eclipse (if you are a developer for example).
    • You can execute the script from a command line (for example you can do this from a third party test manager if you wish)
    • You can automatically execute the script from Oracle Test Manager. This will allow groups of script to be scheduled and it reports on the results for you.
    • You can load the script into the Oracle Load Testing toolset and include it in a performance test suite of tests.

Remember our testing pack is service based not user interface based. You will need to make sure that the Web Services Accelerator is installed.

Essentially Flow Builder builds the flow and script from the components in the pack, Openscript or Oracle Test Manager executes it for you.

Updated Testing Advanced Pack Overview Whitepaper

Mon, 2015-11-02 13:00

An updated version of the Oracle Functional/Load Testing Advanced Pack for Oracle Utilities has been released on My Oracle Support at Doc Id: 2014163.1. The updates to the whitepaper include updates for the release with the following information:

  •  Updates for the new content for Oracle Mobile Workforce Management, Oracle Real Time Scheduler, Oracle Utilities Application Framework, Oracle Utilities Customer Care and Billing and Oracle Work And Asset Management.
  • Updates for the new Component Builder and Component Verifier utilities that allow the addition of new custom components.
  • Updates to the Frequently Asked Questions covering licensing and the common implementation questions you may have about the Advanced Pack.

This new version now only adds new content and new capabilities but utilizes the power and facilities of the Oracle Application Testing Suite (Oracle Flow Builder, OpenScript and Oracle Load Testing) to deliver the ability to rapidly test, implement and upgrade Oracle Utilities products.