In my opinion the name does not adequately capture the functionality but I’m not sure I can suggest anything better. The Expert feature is a combination macro language, best practices scripting, OWB extension SDK, and labor saver. While it might be tough to name the new feature which does a great deal, it is not tough to see the direct applicability of Experts for OWB customers.

OWB Experts is a new OWB feature that allows for building guided experiences within OWB. Experts allow one to expose limited pieces of OWB, and OWB functionality a guided manner. Many programs have this type of functionality, with Microsoft Office being famous for it’s effective use of Fax Wizards, Mail Merge Wizards, etc. NOTE: The OWB product team assures me they have no plans to consider, ever, never in a millions years add a dancing paper clip to OWB.

Why would Oracle provide Experts functionality, to throttle their product back and provide views of it that make it appear to do less? While OWB is an immensely powerful tool it’s learning curve is not insignificant, and I’ve witnessed many competent Engineers/DBAs users overwhelmed by the complexity of the product. Beyond that, as part of their modest Developer Suite seat it’s an inexpensive product to involve many hands throughout an enterprise to make light work.

There are two things you can do with experts, and there are a variety of options on how to do both. You can design an expert, and you can run experts. Designing an expert is typically done by power OWB users. These are your Data Warehouse Architects, ETL Engineers, and DBAs. Experts can be run by anyone, from domain experts who happen to be novices in OWB to ETL engineers adhering to certain best practices. Obviously experts have to be designed before they can be run but it’s helpful to understand where they’ll be run and used before discussing how they’re built.

RUNNING EXPERTS:
Experts can be run by either executing them inside of OWB, or embedding them in third party applications. Embedding them in third party applications opens up a whole slew of possibilities for advanced customer implementations and Oracle partners. While you can embed them in your applications, most OWB experts will be run inside of OWB. There is a nice feature of the Expert implementation that allows execution of a specific expert on OWB client startup. This would be useful if you wanted to provide a limited view so that users would only see the expert, and not really see OWB at all. Of course, you can run an expert the good old fashioned way by executing it from within the OWB tree. There are plenty of options to suit, and suffice to say that you’ll have the capability to provide your experts to users in a method that suits your users.

DESIGNING EXPERTS:
Experts are designed inside of OWB using a graphical interface that is similar to the editors for other OWB objects. An expert is composed of Tasks (things to do) and transitions (process and flow control). In my opinion, it most closely resembles the Process Flow editor in that you are defining a sequence, combination, and processing logic. There is a palette for adding tasks to the expert, a method for creating transitions between Experts, a properties box for setting specific values for task. There are forks and dispatching transitions, which allow the wizard to take a different path based on user input. This feature allows for screens 2 and 3 to request different information, based on the input the user entered on the first screen. The transitions are instrumental in defining order and flow control, however the real usefulness comes from the palette of possible Tasks.

There are numerous tasks that are on the Beta version palette, and I’m not sure the list has been entirely finalized or publicized(there were approximately 20 in the build I used). These are the actual “steps” of the Expert and are usually observed by a particular screen in the application. A few to help you mull over possibilities of Experts in your projects include:

• Custom Dialog : This is immensely useful, as it allows for a quick way to collect responses from the user. It basically pops up a screen that is configured by the Expert designer and receives information from the user (perhaps a table name, or some Oracle connection information).
• Data Viewer : The OWB product has exposed their “data viewer” component on the palette. In some use cases, one needs to display the data from a data table to help the user either confirm they’ve got the correct table, or understand a bit more about the contents of the table.
• Impact Analysis : This helps the user understand what the impact is of modifying an object. This would be useful to guide a user through the modification of a dimension, to ensure they are thinking and noting any impacts before actually making the change.
• Java : This is really a “blank check” in the Expert functionality. This task allows you to embed Java application code directly into this point within the Expert. The possibilities really become quite endless when you consider the full power of Java available in your Expert creation. There will likely be some limitations of how you interact with OWB (or more accurately, how easily one interacts with OWB) but this feature demonstrates the OWB understanding that they are never going to be your only tool/system.

Perhaps it’s appropriate to wrap up with an example use of an expert:

Let us consider a situation where you are using a third party ROLAP tool that has a metadata repository. This is where the OLAP tool goes to understand the structure, hierarchy, cubes and dimensions that are stored as tables inside Oracle. It has it’s own specific metadata format/API and one can make Java calls to a web service to define and describe the metadata of your marts. When your BI team adds a dimension in OWB they must also run through some series of steps to add it to ROLAP tool metadata so that end users can see it in their reporting tool. Every time they follow the same process, add dimension, go to tool and add it.

Consider creating an “Add Dimension” expert in the upcoming release of OWB. The expert would simply:

1. Launch the Add Dimension Wizard
2. Allow the user to fill in the OWB Dimension, hierarchies, levels, attributes, etc
3. Use Java to call some web service and describe the new Dimension to the ROLAP tool

Steps 1 and 2 are easy to just drop into the Expert and configure. Step 3 would require the authoring of custom Java code that would be executed. The key here though is that it is done so in the context of OWB and so has immediate knowledge of what dimension was just added, at what location, with what underlying table name, etc. The benefits of automating these types of tasks has always been clear; minimize actual time spent to accomplish repetitive tasks and minimize errors by programatically enforcing standards and best practices.

Experts hold great potential for power customers, consulting firms, and Oracle Partners to add best practices and efficiencies to an already efficient and powerful tool.

This blog is part of the OWB Paris Early Review series which reviews and comments on several new Paris features.