This year we’ve brought most of the consulting team along to the conference, as a way of getting to see people who are often working away on-site, and so that everyone can get to meet the great delegates, speakers and partners at the conference. Here’s the team at the start of the day, having just set up the demo and waiting for the opening of the exhibition.

And here’s things at the end of the day, during the Exhibition Hall Drinks Reception. We had our famous Rittman Mead beer available again, and it was great to catch up with people such as Paul Vallee, Connor McDonald, Jonathan Lewis, Lisa Dobson and everyone else who stopped by.

The two sessions we ran today were on Essbase and OBIEE Integration, and on the new 11gR2 release of OWB. The Essbase and OBIEE session went well; we had Venkat doing the demos, myself doing the positioning, and then a great questions and answer session at the end where we discussed attendees experiences with the integration and gave some feedback on what worked for us. The slides are available here if you’re interested.

The second session was particularly well attended and was on the 11gR2 version of OWB. Now if you’ve been following our blog, we’ve posted a series of articles on this new release, and we’re particularly excited by the new code template (ODI) features in this release, especially as the integration between the ODI and OWB technologies seems to have been done so well. We were lucky enough to be joined by Craig Stewart, our Oracle ODI representative in EMEA and someone we know well from his attendance at various user group events and indeed our own BI Forum earlier in the year in Brighton. Craig was able provide a “hot off the presses” roadmap slide on OWB and ODI 12g which he’s kindly agreed for me to reproduce here:

What we can take from this are a few points:

• Going forward, the OWB product name will be de-emphasized in favour of “In-Database ETL”, to differentiate itself from Oracle’s strategic data integration platform, ODI
• The 11gR2 version of OWB will be the last in it’s current packaging, and license-wise it’ll now be incorporated into ODI Enterprise Edition. The free OWB functionality will still remain but will be renamed “In-Database ETL” as above.
• ODI 12g is the target version for integration between the ODI and OWB platforms
• There will be an ODI 11g release out in the first half of next year (usual disclaimers apply
• ODI is the strategic data integration platform for Oracle

Again, the slides are available for download here if you want to take a look, and they cover code templates, heterogeneous sources, OBIEE integration, change data capture and web service integration.

Craig is actually going to join me again tomorrow for the ODI and Oracle BI Applications session I’ll be running (14.30 – 15.30, Tuesday, Hall 10b), so again if you’ve got questions on the ETL direction for the BI Applications and the role that ODI will play, come along and we’ll be pleased to answer any questions.

Finally, if you’re around tomorrow (Tuesday) evening, we’re running a BI “Appreciation” drinks session at the Pitcher and Piano, Brindley Place, from 6pm – 9pm. If you’re a BI user, customer, developer, partner etc, or you just know us and would like to join us for drinks and canapes, come down in the evening and it’ll be great to see you.

If you’re interested in taking a look at the accompanying presentation slides, they’re now available on our articles page along with those from the other sessions. If anyone out there has implemented BI Apps 7.9.5.2 and has some project feedback, I’d be keen to hear from you. In the meantime, thanks to aortabisolutions for uploading the video, and there are some more from us on my YouTube site here.

The key to hybrid mappings is in a new type of code template that Oracle ships as part of the public code templates, found within the Globals Navigator in OWB. This new type is called “Oracle Target” and contains a single code template called DEFAULT_ORACLE_TARGET_CT.

This code template is a bit special in that it acts as a wrapper around a regular (or “database resident”) OWB mapping. It contains just some simple PL/SQL that calls the mapping main method, and can be used in a number of interesting ways.

First of all, you can take a regular OWB mapping, copy it and then past it into the Code Template Mappings area, like this:

If you then open up the new code template mapping and display the logical view, it’s the same mapping design and layout as before. If you switch to the execution view, all of the operators are in the same execution unit, which has been set to use the Oracle Module code template. If you then go to execute this code template, it will call the database resident mapping PL/SQL and SQL code as normal, through the mapping’s main method reference.

So it’s interesting to understand what’s happened here. OWB hasn’t “converted” the mapping to an ODI-style mapping, with load code template and integration code templates for source and targets, it’s merely wrapped your database-resident mapping in enough wrapper code so that it can be deployed to an agent and run with all the other code template mappings. On a similar subject, even regular code template mappings that you create using OWB11gR2 aren’t in themselves directly transferrable to ODI standalone and run from there, as whilst the basic technology is the same there are sufficient differences and enhancements in OWB’s approach to make the two types of mapping incompatible. Similarly, you can’t just take an ODI interface and import it in to OWB (at least not yet, though this may come in the future through an Expert, for example) or get each products’s agents to run the others’ mappings.

So, now that we can take whole mappings and convert them to code templates, what about individual mapping elements? You may have noticed that the components palette in the code template editor contains all of the mapping operators that regular OWB mappings use, but obviously some of them (splitters, dimension loads, match-merge etc) will only work for Oracle targets and sources. So how do we use these? This is where the concept of Hybrid Mappings comes in.

Going back to my code template mapping posted yesterday, that takes data out of an SQL Server database, joins it to some data from a file and from an Oracle table, and loads it into a staging table, the execution view for this mapping looks like this:

Now I’ve got a database-resident mapping elsewhere in my project that takes data from the STG_CUSTOMERS table, and loads it into a dimension, like this:

Now I could reproduce this functionality in my code template mapping, by adding in the CUSTOMER_DIM table source and using the ICT_ORACLE_SCD integration code template, but I’ve already got the logic produced and an advantage of using OWB, over say ODI, is that dimension loading is so much simpler. What I can do therefore is copy and paste the constant and the dimension operator from the traditional OWB mapping into the code template mapping that I’ve been working with, and then join it up to the staging table so that it looks like this:

You can then switch to the execution view for this amended mapping. Now this step will require you to change the execution units around, as the Oracle dimension operator needs the staging table to be part of the execution unit, it can’t be fed in to it via JDBC, and so the new execution view for this mapping looks like this:

Now this is definitely interesting as it means that we can mix and match OWB and ODI functionality in our mappings, allowing us to use ICT, LCT and CCT code templates to extract, say, data of non-Oracle sources and then load it into dimensional structures managed, and defined, using traditional OWB functionality. This takes OWB in my opinion to a point where it’s more useful, more functional than ODI – you can create code template mappings, database-resident mappings, or a combination of the two either brought together in process flows, or combined in single code template mappings that make use of Oracle Module code templates.

Now this is all new functionality, and I think it’ll take us a while to come up with a design approach that makes optimal use of this new capability, but one interesting thing for me was that conceptually, I didn’t have a problem with this concept of regular (database-resident) mappings, code template mappings, and hybrid mappings. At Rittman Mead we were on the 11gR2 beta and I worried at the time that these different means of mapping data would be hard for developers to understand, and that we’d end up with two repositories, two sets of table definitions, two types of mapping operators and so on (giving us a sort of “Frankenstein’s Monster” of a tool).

What what the development team at Oracle have managed to come up with though is something really clever – there’s only one repository, one set of operators, one set of table definitions, and you can mix and match these in code template mappings and across your project. The only thing I worry about is that there are lots of places to set mapping configuration options and I can see developers struggling to get everything to validate when first working with this code template mappings, especially if they don’t have prior experience with ODI and its knowledge module approach.

Moving on, if you looked at the before and after execution views earlier in this posting, you might have noticed how the requirements of the Oracle Module code template meant that I had to move the joining of the source data out of the Oracle ICT code template and on to the agent. (as it was accessing data from SQL Server over JDBC). This sort of thing might crop up when you bring the two mapping types together, so the other way of integrating mappings like this might be to keep them separate, but bring them together into a process flow, like this:

Code template mappings can be added into regular OWB process flows in the same way as database-resident ones, and if they share staging tables and interface tables, you can pass data around this way.

Well that’s it for OWB new features for me for a while, but if you’re interested in seeing all of this in real-life at the forthcoming Oracle Open World, and discussing OWB11gR2 development techniques with myself, Antonio Romero and David Allen from the OWB development team, check out this announcement about an “unconference” session that we are running. Other than that, I expect myself, Venkat and Stewart will be posting more on OWB11gR2 new features as we work through them.

Working with the Project Explorer view in OWB11gR2, there’s a new entry at the top of the project tree for Code Template mappings, which you can create alongside traditional OWB-style mappings to best suit the type of integration you are carrying out.

In the example above, I’ve created a code template mapping module called CODE_TEMPLATE_MAPS, under which I’ve created a code template mapping called SIMPLE_JOIN. Code template modules are associated with Agent locations (Agents are the equivalent to Control Center Services in OWB), with a default agent shipping with OWB11gR2 running on an OC4J instance.

You can of course set up agents on servers other than the one that OWB is running on, and I’ve heard rumours that future releases of WebLogic will ship with ODI agents built-in, which would explain why this one is running using the (now sidelined) OC4J.

To start off then, I create a simple code template mapping that moves data from two tables in one schema, through a join, into a target table in another schema. Looking at the mapping canvas, there’s a couple of points to note here:

First of all, although we are using code templates, the way we lay out the mapping is exactly the same as with traditional OWB mappings. There’s a bunch of transformation operators (join, splitter, deduplicator etc), source and target operators, object properties and so on. Now this is very significant, as it means that existing OWB mappings can just be cut and pasted into the code templates mapping area to transfer them across, and you can add far more complexity and logic into your mappings compared to the simple table joins and filters that you get in ODI.

The second point to note is the Logical View and Execution View tabs at the bottom of the canvas. What we are working with now is the Logical View, and this looks just like the mapping canvas that you get with regular OWB mappings. When you switch to the Execution View though, this is the place where you start to make decisions about code templates, and what are called “Execution Units”.

In the example above, we have two execution units, one around the source tables and their join, the other around the target table. The source tables are extracted from using the LCT_SQL_TO_ORACLE load code template, the join takes place on the source, and then data is loaded into the Oracle target table using the ICT_ORACLE_INCR_UPDATE integration code template. Now this is a bit of an artificial example as you’d probably use just a regular OWB mapping for this Oracle-to-Oracle data movement (or use an Oracle Module code template, more on this later in the week), but illustrates what extraction and loading code templates look like whilst keeping our data sources to just Oracle for the time being.

Moving back to the logical view, like regular OWB mappings you can add new columns to a table operator and then synchronize those changes outbound to the repository copy, and you can define whether the mapping operation is an update, insert, insert/update or delete. Using these settings you can define which columns are matched, which are inserted and updated when updates and inserts occur and so on, in the same way as previous versions of OWB.

One slightly confusing thing when working with code templates though, is that certain code templates (incremental load ones, for example) require you to set update keys, column update settings and so on in separate “code template loading properties” sections, which means that you can end up defining the behavior of the load in several places some of which can appear contradictory. I’m sure it’s just a case of getting used to the UI, and of course reading the instructions for the knowledge module you are using, but it is a big confusing at the start and it’s hard not to always end up with lots of warning messages when you try to validate your code template mapping.

You can usually ignore these warnings though, and instead move on to the deployment and run stage. Code Template mappings are deployed using the same Control Center Manager application that you use to deploy regular OWB mappings (though they are deployed to an agent, not to a control center), and when you deploy them, OWB publishes the mapping logic, the code template, JDBC data sources and other information that the agent needs to execute the mapping autonomously from the OWB environment.

Running the mapping is done in the same way as regular OWB mappings, you just select the mapping and press the Start button. OWB then displays the outcome of the mapping (success, warning, failure) and shows you the steps it took with the various execution units afterwards.

So far, we’ve run a mapping where we’ve moved data from one Oracle schema to another using a table join. Where things start to get more interesting is when you bring in non-Oracle data (which is what this feature is really designed for). How does that work? To test this out, I have a table in Microsoft SQL Server that contains some customer data, and to keep things simple I’m going to bring what’s in it into an Oracle staging table. I firstly define another SQL Server database module, and import the customer table definition into it.

My Oracle staging table has already had its metadata imported, and so I go ahead and create a new code template mapping that loads data from the SQL Server table into the Oracle one, via a filter, like this:

So this is the logical view, and I can drop any transformations onto the mapping (certain ones that are specific to Oracle can only be used on Oracle targets, but more on that in a moment) to create my transformation logic. Now, when I switch over to the execution view and press the button to create the default execution units, I can see that one has been created for the SQL Server source, another for the Oracle target, and the filter has been placed in the most efficient place.

The next step is to choose the code templates for each of these execution units. For the SQL Server one, I choose LCT_SQL_TO_ORACLE, like this:

whereas for the Oracle one, I select ICT_ORACLE_INCR_UPD. Then, after I deploy the new code template mapping (along with the datasources, and the code template details) to the agent, I can run it and check that data has gone in correctly.

Whilst this job details view is useful, if you’re used to ODI you will have used the Operator application to look in more detail at the execution of interfaces and packages, what SQL was issued and what errors might have occurred. In OWB10gR2 the equivalent screen can be accessed by selecting View > Audit Information, and you can use this screen to see the scripts that are generated, errors that occur and so on.

So far so good. What if we want to add a file into the mapping as well? My contacts information is held in a file that’s currently sitting in a file module within the OWB project, like this:

I now take a copy of my code template mapping, and then bring this file into the mapping, joining it to the SQL Server table after the filter is applied to it.

Moving back to the execution view, in the first instance the file and the joiner are outside the existing execution views.

Now as I’ve got an Oracle database in the mapping, my plan is to load the CONTACTS_CSV file using an external table LCT template, and to move the join into the TRAIN_STG_EU existing execution unit, so that the SQL Server file is joined to the external table over the file and loaded directly into the Oracle database.

I start this process by selecting the CONTACTS_CSV file and then pressing the “Create Execution Unit” button in the top left-hand corner.

This creates a new execution unit around the CONTACTS_CSV file, and I then select the LCT_FILE_TO_ORACLE_EXTER_TABLE code template to extract from it, as this will work well with the Oracle target that I am loading in to. Setting the SRC_LOCATION option for this LCT code template to the TRAIN_STG_LOCATION used by the TRAIN_STG_LOCATION_EU execution unit will ensure that the physical external table is created in the correct Oracle schema.

I then click on the Joiner operator, and with the shift key held down then select the TRAIN_STG_EU execution unit, and then press the “Add Operator to Execution Unit” button to add the joiner to the existing execution unit.

So now I”m going to natively extract from SQL Server, filter the data at the source, bring in file data via an external table and then join the lot on the Oracle database before loading into the target table.

Deploying and then running the mapping shows the new file execution unit now part of the ETL run, and if I looked at the underlying tables during the ETL run I’d see an external table being created to read in data from the contacts file.

So there you go, I’ve loaded in some data from my SQL Server database and joined it with data from a file to load into my staging area. The last thing in this task that I now have to do is bring in some additional lookup data from an Oracle database, which I initially add to the logical view in my mapping, add into the joiner and then bring the relevant columns into the target table.

Switching now to the execution view, as before the new table is initially on its own, outside any execution units.

What would make sense now would be for this new table to be moved into the TRAIN_STG_LOCATION_EU execution unit, so that it can be joined to the other sources (the table is located in a different schema to the STG_CUSTOMERS table, but on the same physical database). I do this by shift-selecting the CUSTOMER_TYPES table and the TRAIN_STG_LOCATION_EU execution unit, and then pressing the Add Operator to Execution Unit button that appears in the top left-hand side menu bar, so that my execution view now looks like this:

Finally, after deploying and running this new version of the code template mapping, all my data is in the staging table ready for loading in to my customer dimension, defined elsewhere in my OWB project. Which raises an interesting point: in OWB, we have got some very useful mapping operators for loading dimensions and cubes, and it would be great if we could use these as part of this set up – either by using them in code template mappings, or by including this code template mapping into a regular OWB process flow. How does this work? – check back tomorrow for the next part in this series, on OWB11gR2 “hybrid mappings”.

In Oracle Data Integrator, knowledge modules are divided into a number of categories:

• Load knowledge modules, which confusingly are concerned with extracting data from sources
• Integration knowledge modules, which are used to integrate (or in other words, load) data into target databases
• Journalize knowledge modules, used for implementing native and trigger-based changed data capture
• Check knowledge modules, used for data checking and data quality
• Service knowledge modules, used for exposing mappings as web services, and
• Reverse knowledge modules, used when importing table definitions via reading database metadata

When you create an ODI mapping, you create it in two stages. First you define the logical view, which in ODI is fairly simplistic as it always consists of one or more tables being joined and then loaded into a target table (the BI Applications 7.9.5.2 ships some new knowledge modules that provide some extensions to this, but the principle is the same).

Then, once you’ve set up the logical view of your mapping (or “interface”, in ODI terminology) you then assign knowledge modules to each of the stages of the mapping, choosing the most appropriate module for the technology and type of data movement that you are doing.

Now the advantages of this approach are that firstly, you’ve got access a library of “best practice” extraction and load routines across a range of database and other technologies, which you can extend yourself using a templating language. Secondly, it allows you to break the mapping into logical and technical elements, which means that someone with knowledge of the underlying data can wire the data together whilst a DBA can then pick the most appropriate knowledge modules to actually move the data. The disadvantage of this though is that, at least in ODI, the mappings you can create are relatively simple, just joins and filters between one or more source tables, which means that you have to break down what in OWB terms would be a single complex mapping into lots of individual interfaces.

Oracle Warehouse Builder, as I’m sure readers of this blog would know, has up until now been Oracle-centric and has generally generated SQL and PL/SQL in order to move data around. Mappings in OWB contain both the logic of the transformation (the expressions, the column mappings and so on) and details of the technical implementation (whether to use MERGE, to use external tables and so on). Some of the more advanced functionality to use, for example, transportable tablespaces or data pump, has been accomplished by special types of database module that need to be executed outside of regular process flows. From OWB 10gR2, there has been some limited ability to extract from, and load in to, non-Oracle sources, but it’s been tricky to set up and limited to Windows or Linux platforms (ODBC, through the Generic Connectivity feature in the Oracle database), or expensive (the various Gateway products that you can license for SQL Server, Teradata etc).

The 11gR2 release changes all of this by incorporating ODI’s Knowledge Module framework into Warehouse Builder. It does this in several ways;

• You can now build mappings that make use of code templates to move data around
• ODI platform technology can be used to connect natively (via JDBC) to non-Oracle platforms (and Oracle, if you wish)
• ODI Journalize knowledge modules can be used to implement changed data capture on Oracle and non-Oracle sources
• ODI and traditional OWB functionality can be mixed and matched, allowing you to create mappings that use ODI knowledge modules together with OWB Oracle-specific functionality such as dimension loading, match-merge, multi-table inserts and so on
• You can write your own knowledge modules (or code templates, as they are called in OWB) to extend these capabilities to new platforms, new data extraction and loading approaches and so on, a bit like the way you can write Experts in previous releases of OWB.

I’ll be looking at each of these different scenarios over the next week or so, but at a high level, how does this look in the new release of OWB?

In the Globals Navigator part of the main OWB application, as well as getting public transformations, public experts and so on, you now get public code templates. These are code templates (aka knowledge modules) that are certified to work in OWB and ship with the product. You need to have the ODI Enterprise Edition license to use these, but like the Enterprise ETL functionality in previous versions, there’s nothing that warns you of this when you make use of them.

Everthing that makes use of code templates in 11gR2, including native connectivity to data sources and changed data capture, requires the licensing of ODI-EE which also includes the licensing that you used to get with the OWB Enterprise ETL license (Data Quality is still licensed separately). It’s probably fair to say that, with this code template functionality cropping up in many places in this new release, most customers will probably end up going for the ODI EE license when working with OWB in the future, probably more so than the Enterprise ETL license before it. Certainly it’s a more compelling set of features than were offered previously, and with ODI standalone thrown in as well it’s not bad value.

As well as the shipping public code templates, you can also import templates in from an ODI installation. In the screenshot below, I’ve imported all of the code templates in from ODI 10.1.3.5 so that I can subsequently work with Essbase, mySQL and other sources not supported “out of the box”.

The next place that code templates crop up is in the list of database modules that you can create. As before, there are a number of non-Oracle sources and targets that you can create, including SQL Server, Informix, DB/2 and Teradata.

This time though, when you create connections through to the relevant database you can connect natively, via JDBC. You put in your connection details to SQL Server, for example, entering the username, database name, host name and so on (note that you need to download the relevant JDBC drivers from the vendor website, and that in the case of SQL Server it’s only versions 6, 2000 and 2005 that are currently supported), and define the module as normal.

Once the module is defined, you can import the tables, views and transformations in from the non-Oracle source just as you would with Oracle ones. Internally, OWB keeps a record of what SQL Server datatypes map to the standard OWB ones, which makes it possible to create mappings that span across different database technologies.

If you notice the list of database technologies above, it’s pretty much the same as earlier versions of OWB and doesn’t include some of the more exotic ones that ODI supports, such as mySQL, Essbase, Hyperion Planning or Netezza. What you can do though is define what are referred to as new “platforms” in OWB (something you have to do using ODI scripting, setting out the details, driver, datatype mappings and so forth), and thereafter you can use the ODI knowledge modules that refer to these platforms to carry out data loading and extraction. My understanding is that there are plans within the OWB development team to make this process a bit easier by shipping “experts” that automate this process via a GUI.

As I mentioned in my previous posting on OWB11gR2, another place that code templates pop up is in the new support for changed data capture. Taking my SQL Server module defined above, I can edit the module details, tell it which journalizing code template to use for CDC capture, pick my tables to monitor and then make use of changed data capture in my mappings.

It’s in the area of mappings that we see the most changes though, and what’s been introduced in this new releases does nothing less than completely redefine how mappings can be created in OWB. For details on this new feature, check out the next posting in this series, on “OWB11gR2 and Heterogeneous Code Templates”.

Customizations are necessary in the BI Applications when you need to bring in some new data into the data warehouse. This might be because the predefined mappings miss one of the columns you are interested in, or it might be because at the moment it filters out some of the rows you are interested in. You can even add new facts and dimensions to the BI Applications data warehouse, using and extending the framework that comes with the prebuilt content to add your own content. Now as the 7.9.5.2 release uses Oracle Data Integrator and a new Web-based tool called Configuration Manager to replace Informatica and the DAC, the means by which you effect the customizations is a bit different, but the type of customization that you make is divided into the same categories.

Category 1 customization are where you need to add a new column to a mapping, to bring in source system data that was missed out by the predefined mappings. Category 2 customizations are where you want to add new facts or dimensions, whilst category 3 customizations involve bringing in new rows of data from non-packaged sources (I don’t know why bringing in new rows from sources with adapters is not also Category 3, but there you go.)

Now if you followed my postings on this topic for previous versions of the BI Apps, you’ll have picked up on the three most important considerations when customizing the BI Apps, namely

1) Make sure your customizations survive upgrades to the mapping repository,
2) Follow the Oracle methodology as closely as possible, so that Oracle (and others) can work out what you’ve done, and
3) If you change something that’s “out of the box”, make sure you keep a copy of what it was originally.

Now with previous versions of the BI Apps that use Informatica, this was accomplished by only customizing copies of prebuild mappings and putting them into “custom” folders, and by either following the “safe path” through mappings for Category 1 customizations and replicating the functionality of existing mappings when creating your own ones. With this ODI release of the BI Apps, following the methodology is still more or less the same, but the way that you preserve changes through upgrades is a bit different.

Whereas in Informatica versions of the BI Apps you firstly created copies of the SDE_ORA_xxx and SILOS folders and then copied the original mappings into them before customizing them, with ODI you create “versions” of the mappings which are then stored in the repository so that you can recall them later on. To take the same example that I used in this previous posting on the BI Apps 7.9.5 where we are adding columns to the W_ORG_D and W_ORG_DS table, the mapping we need to customize is called SDE_ORA_OrganizationDimension_Customer which we version by selecting this from the right-click menu in the ODI Designer application:

This then presents you with a dialog, where you can enter the version number.

This much like the versioning (snapshot) feature you get in OWB, except for some reason it doesn’t take ten minutes to run ;-)

Then, assuming you’ve got some new fields to add into your warehouse tables,, you should version the Model folder that contains all of the warehouse table definitions (you can only version the folder, not the individual table), then go and add the columns into the table that you need to add.

Then, still within the Model view of the ODI Designer application, you right-click on the BI Applications model folder and choose the Generate DDL option. Then after selecting this table from the sync list, ODI deploys the additional columns to the warehouse table.

This is a big improvement over the releases that use Informatica, as you need to change the table definition in both of those tools rather than just the one, the ODI Designer application.

Next it’s time time to edit the interfaces. Mappings in the ODI release of the BI Apps consist of a folder, containing a package and a number of interfaces to implement full and incremental loads. Some of these interfaces use a new knowledge module that implements inline views, that are then used to replicate the mapplet and source qualifier features in Informatica so that access to the underlying EBS tables can be abstracted into a simple interface.

We then edit the SDE_ORA_OrganizationDimension_Customer.SQ_BCI_CUSTOMERS interface as it’s this one that will map onto the relevant EBS tables. The first step in editing it is to add new columns to the interface target datastore to hold the new columns.

Then you link into this new column the source column that you want to bring through.

After this the process is very similar to when you are using Informatica and the DAC – you feed the new column across from the SQ_BCI_ interface into the main interface that loads the dimension staging table, then you repeat this for the SIL mapping that actually loads the dimension. It’s just a different mapping approach and set of tools to use.

Category 2 customizations, where you define and then load your own facts and dimensions, are of course a bit trickier. Like BI Apps customizations that use Informatica and the DAC, you need to add DATASOURCE_NUM_ID and INTEGRATION_ID columns to your dimension staging tables, and these plus ROW_WID and ETL_PROD_WID to the SIL mappings.

In addition, the same sorts of variables, such as IS_INCREMENTAL, TYPE2_FLG and so on, are passed to the master package for each set of interfaces but this time, instead of you implementing these features using packaged Informatica transformations, most of them are implemented through features of the model datastores (SCD2 type 2 handling, for example) and the new BI Apps-specific knowledge modules that ship with this release. So again logically, the process is the same as before, but there’s a whole new set of tools and techniques to learn if you want to do this.

So what happens then when a new release of the BI Apps comes along? This is where versions come in. What you need to do is to make sure you create a new version of this interface before you apply the update, then apply the update and create a new version, and then compare the two versions.

By doing this you can see what’s changed in this new release (presumably your customization is no longer there), and so you can either restore your old version, or go and apply the customization again if there’s something you want to preserve in the new release of the interface. Of course it’d be nice if you could automatically reapply just your customization but for now, this is the best approach.

So there you go. In four parts, there’s an introduction to the BI Apps 7.9.5.2, a look at the underlying technology, steps on how to do the first load and now a look at customizations. If you’re interested in learning more about this release, come along to my session at this year’s Open World, or even better come along to our Training Days event just after in London where we’ll cover this release in more detail.

The first step in performing a load is to start up the Configuration Manager and define the execution plan. If you’ve used the previous releases of the BI Apps that use Informatica and the DAC, you’ll know that you can either run one of the predefined execution plans or you can define your own, using a list of subject areas that you select. In 7.9.5.2, the Configuration Manager doesn’t provide you with any predefined execution plans and so you need to use the tool to create your own. You start off by creating a connection through to the Oracle database that contains the metadata tables used by the Configuration Manager (these are a much smaller set of tables than used by the DAC, as details of the execution plans etc are actually held in the ODI Work Repository).

Once you’ve created this first connection you can save it, so that you can just select it from a list next time you log in. Once you’ve logged in, you are presented with a list of options, to manage connections, manage parameters, edit, run and then monitor execution plans.

“Manage connections” allows you to define the connection through to the ODI workflow agent, and to the schema that holds the Configuration Manager tables. This is optional but saves you having to retype it all every time you submit an execution plan for running.

You can also edit the parameters used that are global (are independent of specific ETL runs), common (apply to all subject areas) or application specific (specific to a particular module, such as Financials Analytics). I leave these as the default, I also haven’t updated or amended any of the domain values CSV files that ship with the BI Apps as I’m running against a subset of the Vision EBS database and don’t really know/care about the specific codes used in this database.

Now it’s time to define the execution plan. I click on the Administer Execution Plans link and start selecting the subject areas. These map to the license options for the product and are restricted to the modules that this release supports (see this posting for more details). I select Backlogs, Booking Line, Cycle Lines and Invoice lines from the Order Management module.

There’s an option at the bottom of the select list to “Synchronize package structure”, which you can also do when saving the execution plan. What this step actually does is a bit unclear; looking at the docs, it says:

“In order for the package structures to be displayed correctly on the Package Structure tab, the subject areas associated to an execution plan must be synchronized within internal Oracle BI Applications Configuration Manager tables. If you do not synchronize the package structures when creating the execution plan or when you made changes to the subject areas associated to the execution plan, you must synchronize by clicking the Synchronize package structure button that appears on the Package Structure tab in order to get correct package structure. The synchronization process may take up to several minutes depending on the network traffic between the Oracle Business Analytics Warehouse database and the Oracle BI Applications Configuration Manager installation.”

The schema used by the Configuration Manager only actually has one table though, and what it appears to contain is a list of “transactions” associated with the Configuration Manager, like this:

If you view the contents of the BLOB as an XML file, each one contains something a bit different and, I think, is storing details of parameter changes, setting up of execution plans and so on. Here’s a look at the entry that was created just after I defined the above execution plan:

You can see the name of my execution plan mentioned in the XML, so I guess (a) this table stores details of the execution plans, parameter values and so on as you create them, and the synchronization step takes what’s in these tables and copies it across to the ODI Work Repository.

Once you’ve created the execution plan, you can view its structure in the Configuration Manager application.

Notice how the execution plan package is structured; there is a “Master Execution Plan” at the top, which then has “Master General”, “Master SDE Facts”, Master SDE Dimensions” and so on. Within each of these are packages for the various dimension categories, and these then go down to the individual mappings that you’ll need to run. If you saw my previous article on how ODI holds execution plans you’ll have seen that these packages and mappings translate to packages and interfaces in the Project View in ODI Designer, like this:

The numbers next to the packages indicates the ETL phase for the package, the complete list of which looks like this:

So how about we try and run the execution plan. To do this, you can either start it from the ODI Designer application (you can use this to schedule execution plans as well), or you can run it on-demand from the Configuration Manager. I run it from the configuration manager and enter the details for the ODI super user (SUPERVISOR).

After the execution plan is started, you can switch between the Monitor Executions view in the Configuration Manager and the Operator ODI application to see how the plan develops.

Things start off with some general routines to create indexes, truncate staging tables, refresh the execution plan and so on.

Taking a look at the execution plan status in the Configuration Manager, all looks OK at this stage.

Going back to the Operator, you can see the Workflow agent kicking off Interface agent jobs to load the individual dimensions, at this point using the SDE mappings.

The view from the Configuration Manager still looks good, as well.

About five minutes later though, I notice that the load has ground to a halt. Taking a look in the Operator, I can see that one of the mappings has failed.

The Configuration Manager also shows an error, but also shows the log which indicates that the mapping has failed due to a table being missing.

I half-expected this as the dataset I’ve got is a stripped-down version of the Vision dataset, originally designed to be demo’d with the 7.9.5 version of the BI Apps. Even for point releases such as 7.9.5.2 some of the mappings change though and require additional tables that aren’t in my dataset.

So which table is missing? To find out, I go back to the Operator and have a look at the SQL that this step was trying to execute.

So the step that failed was one that was trying to create a view over one of the tables in the EBS schema, and for whatever reason this table doesn’t exist.

Now as the ODI Model View contains the definition of all the tables that are expected as sources for the mappings, to get around the problem I use the ODI Designer to generate the DDL for this table and then apply it to the EBS source schema. Then, as you could do with the DAC, I go back to the Configuration Manager and restart the execution plan. As the mappings in the ODI repository are designed to be restartable, after a minute or so I go back to the Operator and check the progress again.

A few minutes later, the execution plan stops again, and looking at the Operator I can see that the Workflow agent has failed this time, whilst trying to create an index.

Looking at the error message associated with the step, I can see that a unique index has failed to create because the table has duplicate values in the indexed column.

For some reason the W_GL_ACCOUNT_DS dimension staging table has got duplicate values in the DATASOURCE_NUM_ID, INTEGRATION_ID and the source effective from column, which is strange as this indicates a problem with the source data (there are duplicates in the source EBS table). To start working out what’s gone wrong, I first run a query on the W_GL_ACCOUNT_DS table to find out which INTEGRATION_IDs are duplicates.

Sure enough, there are two that are duplicated. Now even if I’ve run this mapping a few times we shouldn’t get duplicates as the table is truncated each time that the mapping is run, so there must be duplicates in the EBS table that provides the source. So which source table populates this mapping?

Now with the old DAC you could have taken this table name, viewed it in the DAC Console Design view and then displayed which tasks had this table as a target. This is a bit trickier in 7.9.5.2 as there’s no UI for querying the relationship between tables and mappings, so I instead go back up the list of completed mapping steps and find the package that called this index creation step; I then look up the steps and see the view that’s created to provide information for the table load.

So the view is created over an SQ_BCI_ table, which is something that the Source Qualifier interfaces that I mentioned in my previous posting creates to mimic the mapplet and source qualifier transformations that Informatica uses. Going back to the Designer application, I can see that the mapping to load the W_GL_ACCOUNT_DS table consists of a package that calls two incremental load interfaces and two full load interfaces. The ones in yellow are the “source qualifier” interfaces that retrieve the data from EBS, the other two are the interfaces that load the warehouse staging table.

Taking a look at the full load interfaces, I first look at the interface that loads the W_GL_ACCOUNT_DS table to see where the INTEGRATION_ID column is populated from.

So INTEGRATION_ID is populated from the CODE_COMBINATION_ID from the SQ_BCI_ interface. So where does this interface get the CODE_COMBINATION column from?

So it comes from the GL_CODE_COMBINATIONS.CODE_COMBINATION_ID table. Now it’s a case of running a query against that table, and maybe I’ll find a duplicate, or it could be that there are no duplicates but the SQ_BCI_ interface creates some because of the join that takes place in order to load the table. However looking at the data that’s been loaded into the table, it actually looks like it’s valid but I need to include another key value in the integration ID so that it becomes unique.

The task now is to resolve this issue and then work through any similar issues until the load completes without error, a task that in my experience usually takes up to a week to complete (meaning that including the install, working out these data issues and then getting the RPD set up, I usually budget for two weeks to get the first numbers up in front of the client) for initial evaluation.

If all else fails and you can’t get a mapping to run, but you want to mark it as completed and run the rest of the mappings in the execution plan, in theory you can set the status of the session to “Done” from “Error”. This should then allow the rest of the process to complete as if the erroneous step completed correctly (although your data of course may not now be consistent), however when testing this I found that even though I could mark the session as “done” and other steps then started running, this step later on got marked as “error” again later so I don’t think it works in quite the same way as the equivalent feature in the DAC Console.

If nothing is working, you can mark the whole load as having completed or even reset (truncate) the warehouse tables in order to start again.

So there you go. As with the versions of the BI Apps that used Informatica, your first load will probably take a couple of attempts to go through and you need to know how to diagnose errors, restart the load and monitor progress in order to complete the task. The process is a bit different to using the DAC and Informatica but if anything, the mappings are a bit simpler as all of the SCD2 handling, ETL_PROC_WID applying and so on is done through the various knowledge modules. In the final posting on this topic later in the week, I’ll be completing things by talking about customizations, and how they work in this new version.

Going through the install and setup process, the basic approach of installing Oracle BI EE and then the BI Applications is the same as before, except this time there are less BI Apps modules to select from (see my previous posting for details). You obviously don’t install Informatica any more, you install ODI 10.1.3.5 instead, and once you’ve got all of these installed it’s time to set up the data sources.

Now setting up data sources is one area that’s greatly improved in this release. With the previous version of the BI Apps, you had to define data sources in both the DAC and the Informatica Workflow Manager, and you also had to define connections between the DAC and Informatica and between the DAC client and the DAC server (and in pre-7.9.5. releases, between the Informatica Repository Server and the Informatica Integration Server). Now you just define your data connections in the ODI Topology Manager, like this:

The connections themselves are defined as JDBC connections, and as database links for Oracle-to-Oracle mapping flows. You also use this interface to define the connections to the interface and workflow (scheduling) agents, and that’s about it (you also need to define the link from the Configuration Manager to the ODI repository, but that takes just a second and again is through JDBC). So score 1 to BI Apps 7.9.5.2 for this welcome simplification.

In the previous releases of the BI Apps, you import the BI Applications repository into Informatica using the Informatica web-based Console, and then you import the DAC repository into the DAC and then create the required containers for your particular source systems. In 7.9.5.2 you first import your ODI Master Repository which contains entries for the various sources and agents you are going to use, like this:

Then shortly afterwards you import the ODI Work Repository, which contains the actual PLP, SIL, SDE etc mappings and the various master execution plans for sequencing them together. All in all this takes a couple of hours, around the same time (possibly a bit shorter) than the Informatica release of the BI Apps.

Once you’ve imported all of the mappings, you can see how they are stored in the Project view of the ODI Designer application.

In the screenshot above, you can see the folders that map to the Adapters that you got in the previous release (SDE_ORA11510_Adaptor, etc), with the naming consistent with the Informatica release but of course only with support for EBS 11.5.10 as a source. Under the Mapping folder are folders for utilities and other tasks that you will need to carry out, together with the master (template) execution plans that are leveraged in the Configuration Manager application.

Taking a closer look at one of the mappings in the SDE folder, you can see that it corresponds to a single mapping, and a single workflow, in the previous Informatica-backed BI Apps releases. If you expand the mapping you can actually see that it’s a “package” (equivalent to a “workflow” in Infomatica), with the package calling a number of ODI interfaces. The ones with blue icons are ODI interfaces as we would normally know them, whilst the ones with a yellow icon correspond to a cross between the “source qualifier” transformations in the Informatica mappings and the “mapplets” that were used to encapsulate access to EBS data areas such as customers or invoices.

In the list above, the AP_XACT_FS interface is used for incremental extraction of AP data from EBS and uses the SQ_AP_INVOICES_ALL interface as a source, something that’s now possible through a new “inline view” knowledge module that ships with the BI Apps. Taking a closer look at the AP_XACT_FS mapping you can see it using the SQ_AP_INVOICES_ALL interface as a data source in the same way that the Informatica mapping used mapplets and source qualifier transformations:

Looking then at the corresponding, SQ_AP_INVOICES_ALL interface, you can see that this is where the main extract logic goes, corresponding to the mapplets and source qualifiers in the Informatica version.

It’s a similar story with the SIL mappings, with SQ interfaces providing an abstraction away from the main data sources and thereafter providing the main data source for the regular ODI interface. One significant different though between the old Informatica mappings and the new ODI ones are that much of what you uses to do with custom Informatica transformations – get the ETL_PROC_WID, check that rows haven’t been inserted already, handle SCD2 history tracking and so on – is either handled by new BI Apps-specific ODI knowledge modules that are selected in the “flow” part of the interface, like this:

or, in the case of SCD2 handling, are defined as part of the column properties in the ODI Designer Model view, like this:

From what I can see these changes are either driven by changes in the way that mappings work in ODI and Informatica – in Informatica, like OWB, a mapping can have several steps and can make use of shared transformations, whereas in ODI mappings translate to simple SELECT, UPDATE etc statements – or because ODI has more in-built data warehousing functionality in the form of it’s knowledge modules so that we don’t need to code a solution for ETL ID handling, or for SCD2 handling, each time we write a mapping. Of course the interesting test of this will be when we try to customize an existing mapping or write our own new one, and of course it’ll be interesting to see how well the ODI-based mappings run compared to the new set-based ODI ones.

There are a number of utilities that come with the mappings, scenarios and interfaces, that you can use to reset (truncate) the data warehouse, mark execution plans as having completed, generate the scenarios at the start, create extract views (presumably over the EBS tables) and so on.

In the next post I’ll look at performing the first data load, and we’ll see how these utilities are used during a data load. It’ll also be interesting to see how execution plan restarts work, how easy it is to debug failed mappings and so on.

The execution plans themselves are stored in the ODI repository along with the mappings, with an initial set of master execution plans that are then added to as you create your own customizations. I’ll cover customizations later, but for now I’ll say that whilst the customization process is similar – you have category 1,2 and 3 customizations and you follow the “safe path” through the predefined interfaces – the way that you preserve customizations through upgrades and patches is a fair bit different. More from this in a later post.

Moving on to the Configuration Manager, again one benefit of this and ODI compared to the DAC and Informatica is that you only have to define tables, columns and so on once (in the ODI repository) and not twice, in the DAC and the Informatica Source and Target Analyzer utilities. One downside though is that you can’t use the Configuration Manager to take a target table, trace it back to the task that loaded it, then trace this back to the SDE task and then the source tables that provided its data, although I’ve seen demos of Oracle BI EE running reports that show the data lineage in the ODI repository, so presumably that will replace this DAC functionality.

Defining the execution plan is as simple as selecting the subject areas (no generation of parameters, and no generation of the ordered task list, so I wonder how the final tasks dependencies are generated when you select more than one subject area?) and then saving the resulting execution plan.

Once the execution plan is defined you can take a look in the Package Structure view, like this:

This is not too dissimilar to the ordered task list in the DAC (though handily, it’s shown in a tree structure), and then you can run it either manually from the Configuration Manager, or manually or scheduled from the ODI Designer application.

Unlike the SIL workflows in Informatica, the SIL packages that are executed from the Configuration Manager contain logic for both incremental and full loads, and they also call lots of individual interfaces and ODI tools rather than just the one Informatica mapping that Informatica workflows call.

The way that execution plans work is obviously a bit different to the Informatica versions of the BI Apps. In those versions, the execution plan exists only in the DAC repository and is used to make calls out to the Informatica Workflow Manager to run individual mappings that correspond to DAC tasks. In the 7.9.5.2 release, the steps to load the warehouse, then to run the SDE, PLP, SIL etc mappings, then within these the mappings that correspond to the HR, OE, Financials etc modules are held in a hierarchy of ODI packages that themselves call the various SIL, SDE and PLP mappings.

Presumably then this is how the “ordered task list” step is skipped, as the sequence in which the mappings are executed are defined within this master execution plan packages which are then run in parallel for each stage in the ETL process (the numbers next to the various stages in the above screenshot). I’ll cover this more in the next two postings, where I’ll look at performing the first load and then making some customizations.

Finally, once you’ve defined the execution plan (something you can only do in the Configuration Manager), you can actually execute and monitor it directly in the DAC Operator application, which gives you greater visibility as to what’s gone wrong and where things are at the moment.

In the view above, you can see the mapping tasks being executed by the interface agent, and the various supporting tasks being executed by the workflow agent. Two of the mappings in the interface list have failed, so when we come to do the full load later in the week we’ll have to see how we can fix these.

First of all it’s worth setting out what this 7.9.5.2 release does, and what it doesn’t do. First of all, the sources and targets that it supports are only a small subset of those covered by the 7.9.5 and 7.9.6 releases. The only source supported is Oracle E-Business Suite 11.5.10 which necessarily is only on the Oracle Database, and the only target supported is Oracle 10gR2. Within the BI Apps, the only modules that are supported are Financials, Human Resources, Supply Chain & Order Management, and Procurement and Spend and moreover, as this is the 7.9.5.2 release – a branch of the 7.9.5 main release – you don’t get any of the new subject areas that are in the 7.9.6 release which continues to use Informatica. One other important thing to bear in mind is that there is no guarantee that there’ll be a 7.9.6.x release using ODI, and therefore you might need to wait until the 11g BI Apps release before you can take advantage of areas like Projects, a wait that may well be twelve to eighteen months or so (assuming that BI EE 11g is out in the first half of 2010). Finally, if you’re a customer looking to implement the BI Apps, there are going to be far fewer people out there with 7.9.5.2 experience than with mainstream BI Apps experience, and so you’re going to really have to want to use ODI with the BI Apps to go for this version – for most customers I’d still recommend going down the Informatica route at least until the 11g release.

If you take a look at the architecture of the 7.9.5.2 release of the BI Apps, you can see that pre-built ODI interfaces, packages and transformations take the place of the equivalent mappings, workflows and transformations that come with the 7.9.5 and 7.9.6 version of the BI Apps. Knowledge Modules within ODI handle the extracts, loading and transformation of data between source and target and the BI Apps ships with a number of custom knowledge modules to replicate, for example, the mapplets feature in Informatica.

The stated aims for Oracle in this ODI-backed release are firstly, to speed up data loading through the use of database set-based transformations; secondly, to make deployment quicker and simpler, and thirdly, to make all the technologies more tightly integrated. For the first objective, we’ll have to wait and see until we can run the same execution plans using both Informatica and the DAC, and I’m hoping to have these test results in place for my session on this release at the forthcoming Open World in San Francisco, and for our Training Days event just after this in London. Deployment and Integration is however better (at least once you work out how it all installs, it took me about six attempts before I got it all working).

If you look at this topology diagram from the Oracle documentation, there are three servers involved in the Informatica-driven 7.9.5 and 7.9.6 architecture, made up of the repository and integration servers for Informatica, and the DAC server that controls the Informatica workflows. There are also Informatica and DAC clients which are used for customizing mappings, and for controlling and monitoring ETL execution plans respectively.

If you take a look at the corresponding topology diagram for 7.9.5.2, the number of servers has gone down to one, as has the number of clients.

Now I think this is slightly disingenuous as you typically use two ODI agents – one for workflow, one for executing the packages – and there are also two clients, the ODI client and also the Configuration Manager which takes the place of the DAC. But it’s still definately the case that the 7.9.5.2 release seems to have less “moving parts”, there is no DAC server (with all of it’s technologies to learn) controlling Informatica (another, non-Oracle technology to learn) and there’s no DAC repository as all of it’s functionality has now been moved into the ODI repository or into a set of tables used by the Configuration Manager. It’s not quite the simplification that Oracle claim but if you’re already an Oracle shop and use ODI, it’s just another set of ODI projects and models that you need to run.

So once you’ve got it all installed, what does it all look like? Well once you’re in the ODI Designer application, the Projects view shows you all of the PLP, SDE, SIL and so on folders that correspond to the various adapters in the Informatica repository, except of course they only cover EBS 11.5.10 as a source.

You can also see the area where execution plans are stored; the concept around these is a little different to how they worked in the DAC before, but you still select subject areas to load and let the Configuration Manager (the DAC replacement) turn these into calls to the equivalent to Informatica workflows in this release, ODI “packages”.

The ODI Designer application also holds the data definitions for the source and target databases, and you use this tool to create the data warehouse tables in the target database before you commence your first load. If you’ve read my posting on adding partitioning to the 7.9.5 release of the Oracle BI Applications you’ll be interested to note that the 7.9.5.2 release supports range-based partitioning on tables (though not compression, though this should work if you manually apply it after the initial table creation), presumably creating bitmap indexes “local” rather than the default “global”.

So with the DAC gone, what’s it’s replacement? Well much of the functionality has moved into the various ODI client tools and the DAC repository itself is now just part of the ODI project metadata, but you still need a user-friendly tool to select and then run the data warehouse load routines and the tool that does this is called the Configuration Manager. This is a web (ADF)-based application that runs on Weblogic that currently you need to separately install after the main BI Apps installation (I understand in future this will be automatic, at least for Windows platforms). This has a subset of the functionality of the DAC Console, allowing you for example to construct and then run execution plans, however it doesn’t have the data lineage and metadata exploration features that I found useful in the DAC Console, presumably this functionality will be (or already has been) replaced by packaged reports that run against the ODI repository for use with Oracle BI EE.

The Configuration Manager interface is quite easy to use, once you log in you are presented with a list of options where you can define parameters, build and then execute an execution plan, and then monitor the execution of those plans.

Creating execution plans is a simpler process than with the DAC, as you don’t need to define and populate the various parameters that are passed between the DAC Server and the Informatica Server, and there is no “create orderered tasks” step either that sequences all of the mappings that are required to load your chosen subject areas. In the screenshot below, you can see where I’m choosing the various subject areas that I want to see in my execution plan.

In future postings in this series, I’ll look in more detail at the technical differences under the covers in this release, how you go about doing the initial load and how the customization process works. For now though, you can download BI Apps 7.9.5.2 from OTN, and if you’re going to use it you’ll need a full license copy of ODI 10.1.3.5 as well in order to use the mappings.

Like last year’s Training Days event, the focus is on in-depth technical knowledge around Oracle BI EE, Essbase, Oracle Data Integrator and the BI Applications, with each of us running several sessions over the three days. Unlike other “beginners-level” courses this event focuses on real project issues and we’ll be going through the reality of designing, architecting, performance-tuning and integrating products across the range of Oracle’s BI and EPM product stack. I’m particularly pleased to have Venkat on board because of his deep knowledge of OBIEE and Essbase integration, and it’s great to have Christian presenting as well as he’s worked on so many successful OBIEE and Oracle BI Applications projects. Anyway, here’s the agenda for the three days:

• Day 1
• Oracle BI and EPM architecture overview – Mark Rittman
• Oracle BI EE Data Modeling against DW and 3NF sources – Mark Rittman
• Oracle BI Delivers + Integration with Java and BI Publisher – Venkat Janakiraman
• What’s new in Oracle BI, DW and EPM from Oracle Open World – Mark Rittman
• Day 2
• Oracle BI EE Data Modeling against Essbase – Venkat Janakiraman
• Leveraging MDX functions and calculations in OBIEE – Christian Berg
• Integrating Security across OBIEE and EPM – Venkat Janakiraman
• I can do this in Hyperion – how do I do it in OBIEE? – Christian Berg and Venkat Janakiraman
• Day 3
• OBIEE Systems Management with OEM BI Mgmt Pack – Mark Rittman
• OBIEE Configuration Management Best Practices – Christian Berg
• ODI functionality in Oracle BI Applications – Mark Rittman
• ODI Integration with Essbase, Planning and Oracle EPM Suite – Venkat Janakiraman

As with our BI Forum in Brighton earlier in the year, this is a great opportunity to meet and train with real-world Oracle BI and EPM consultants who have real project experience to back up their training materials. With lots of discussions and the opportunity for you to bring your own laptops and try out some of the techniques we discuss, this is a rare opportunity to take your OBIEE, Oracle BI and EPM knowledge up to the next level. Unlike the BI Forum though, this is an intensive three days with just three trainers, where we’ll look at topics in much greater detail and follow a common theme from start to finish.

Like last year, you can either book for just one day, or you can book for all three in a “three for the price of two” deal (though last year, everyone ended up staying for all three days). There is also an “early-bird” offer where we are discounting both rates by 10% up to the end of September, so if you’re interested in coming take a look at the event website for more details. The rate includes lunch on all three days and a special meal on the second night where we can kick back and discuss the world of Oracle BI in one of London’s top restaurants.

I’m really excited about this event and I know Christian and Venkat are as well. We only have twenty spaces available, so if you’re interested make sure you register now and we’ll see you in London in October.