Oracle licensing for VMware

By Paul Bullen, Senior License Consultant, Rocela.

Recently, there has been renewed interest on VMware’s position regarding Oracle Certification, Support and Licensing.

This document lays out, amongst other popular Oracle-on-VMware topics, some logical and reasoned discussion about using DRS Host Affinity in order to limit Oracle license requirements within a VMware cluster. They suggest that limiting a VM to a particular physical host (or subset of hosts) within a cluster will reduce the license requirement and that only those physical servers require licensing for Oracle.

Understandably, this can have the potential to massively change your licensing requirements – the general stance has been that all physical nodes within a cluster, regardless of whether they are running a VM with Oracle on it, need to be licensed.

The VMware article is logical, interesting and its assertions are very positive, however it is worth remembering: this is a VMware paper. It is not underwritten by Oracle, and ultimately it is Oracle who decides how their products are to be licensed.

We work with clients using VMware and Oracle every day: we are unaware of any change of general stance from Oracle. Therefore, you should be fully aware of the potential licensing implications should Oracle audit your use of Oracle on VMware clusters.

Declaring an Oracle Unlimited License Agreement – Part II

Paul Bullen, Senior License Consultant, Rocela

My previous blog entry discussed the importance of making sure your staff understands what an Oracle ULA means to them and how they use Oracle software. I also mentioned that on-going management of your software deployment during a ULA is even more important than ‘normal’ licensing.

One of the reasons I mentioned tracking your software deployment during the entire term of the ULA was to ensure that you are getting the value you expected out of your investment. The other reason is so that you can accurately declare your usage of the ULA products when the Unlimited Deployment Period has finished.

To recap, with a ULA, you buy the right to use as much of the defined product as you wish during a set period (typically 3 years, but can be between 2 and 5 years), at the end of this period, you declare your usage of the product and this should become your perpetual license: your usage effectively ‘crystallises’ at this declared number and you then own that many licenses to do with as you would any other normal Oracle perpetual license.

If you do not track your usage throughout the term of the ULA, you may find yourself frantically undertaking an Oracle audit of your own usage on the run up to the declaration date: doing so may mean you ‘miss’ installations (and hence they are not licensed) or you count incorrectly. Measuring for an Oracle ULA is not quite the same as for ‘normal’ Oracle licensing—there are some small but important differences between the definitions.

Once you have measured your deployment (and let’s be honest, tracking and counting Oracle software accurately can be very difficult), you need to fill in a declaration form: this is what Oracle will use as the basis for your perpetual license. However, it is worth bearing in mind that there is a potential for audit at this point—understandably, Oracle need to be reassured you are actually using the software you are declaring to them and not just making up a number: they may ask to review your inventory and you should be prepared to share this with them. This is another reason to make sure you invest in this process and that you thoroughly understand your estate and the terms of the ULA.

As this is the last in the series of blog posts for ULAs, I’ll try and summarise:

• ULAs are a very powerful and beneficial (usually) way of licensing Oracle. They are significant purchases that require assessment and planning.
• You may use as much of the software as you like during the period of the ULA
• There is no true up, the opex and capex are set from the start
• Education and ‘awareness raising’ about the ULA is key to it being used correctly
• On-going usage tracking and management are even more important with a ULA
• ULAs are a significant investment and should be negotiated, managed and declared with expert advice

If you are considering a ULA and need to understand the basics, have a ULA and require assistance managing, or are approaching your ULA expiry and need help deciding on declaration or new purchase, then contact us for assistance. As you have been reading, we know a great deal about ULA’s and can steer you in the right direction.

Declaring an Oracle Unlimited License Agreement – Part I

Paul Bullen, Senior License Consultant Rocela

Last time we took a very high-level view of what you need to consider if you are weighing up purchasing an Oracle Unlimited License Agreement (ULA). Let’s now assume that your projections and the cost of a ULA make it worthwhile and you’ve gone ahead and entered into a ULA: well done! So what now?

Firstly, you must communicate the ULA purchase internally and what it allows the appropriate software users (anyone who can influence the amount of Oracle software your business will deploy) to do. It is important that full details of what the terms of the ULA and the products involved are passed on. Forwarding a copy of the Ordering Document to the DBAs is definitely not the best way to do this: DBAs generally won’t have the inclination to read the details of commercial documents! Instead, you must distil the content and tell people what products are available for unlimited deployment, and for how long they remain unlimited.

This seems obvious, but from our extensive experience working with customers who own ULAs, it is clear that often over 30 pages of ordering document can sometimes dangerously be interpreted as:

“Use as much Oracle software as you want!”

There’s a real danger that the actual allowance and detail of the ULA gets lost between those who negotiated it and those who ultimately use the software (this is a problem outside of ULAs as well, but the potential risk when the belief that all Oracle software is available for unlimited use is bigger).

So, assuming your staff know what products they can use and for how long, do you wait until a month before the ULA declaration date and then start preparing to declare? If anything, owning a ULA means you have to pay more attention to SAM and the amount of software you deploy and use: you need to know that you are following or exceeding your forecast – there is little point in having a ULA and not gaining the return you expected. In fact, there is a danger that you deploy far less of the software than forecast (e.g. change of product choice, cancellation of a project) and suddenly the whole business case for the ULA is no longer valid.

Your ULA is a massive investment for your company: it is worth putting effort and time into ensuring it is being used properly as well as having your methods and usage reviewed by an independent expert such as Rocela.

There have been a number of occasions where we have seen clients with a ULA who do not fully understand how to use them. I’ll keep repeating the same message:

A ULA allows you to deploy an unlimited amount of a set of products for a one-off upfront capital cost upon which the support is based. There is no true up; there is no change to the support fee (excluding RPI).

So, to summarise:

• Ensure your software users understand what the ULA allows them to use, and how

• Track your Oracle software deployment: not just the ULA products but related products

• Ensure you compare your usage against your ULA business case

• ULAs are huge investments and should be properly managed and reviewed during their course

• Use your ULA: understand and take advantage of its features

Next time we’ll take a look at declaring your ULA in more detail. In the meantime, please ask any questions or leave any comments below.

Virtualisation – The Reality, not the hype. Final Part

By Tam Kyle, Senior License Consultant, Rocela

Before I launch into the thorny topic of Oracle licensing when virtualising, it’s probably worth reminding ourselves of what has been discussed beforehand … briefly!

So, Part I covered what virtualisation is and why companies are so keen to take advantage of it with Part II discussing the sort of problems organisations encounter when virtualising and at a high level, how you can avoid these issues in the future.

And so, to Part III – the impacts and considerations of Oracle licensing when virtualising. Where to start?

Cost saving or cost avoidance?
Let’s start with the obvious – money. What are you trying to achieve? Direct cost saving or cost avoidance? Do you actually know if it’s possible to reduce or avoid Oracle costs? If you have a fixed maintenance stream, then you are paying for what you have already bought irrespective of the actual amount of usage. Your support fees will not necessarily reduce in line with reduced usage – all you will have done is freed up licenses for use elsewhere in the business, all the while paying support for shelfware – but that might be beneficial to you as opposed to dropping the bottom line.

Your license contracts will determine whether and indeed how you can terminate licenses and it’s certainly not as easy as saying, “I’ve virtualised, therefore my footprint is smaller, so I’ll pay less.”

Smaller footprint
And whilst we are on that topic, are you sure that your footprint is smaller? In other words, have you considered whether your virtualisation technologies allow licensing in a sub-capacity context? In plain English, have you been able to establish whether you only need to license the bit of the box that you are using? As it turns out, this is not necessarily always the case. My fuller publication will walk you through a few scenarios with some surprising conclusions.

Server Clustering
One of the great benefits of some virtualisation technologies is the capability to join physical servers together (clustering). This allows for resilience and the seamless moving of virtual machines between hosts within the cluster. However the license terms underpinning this may prove prohibitive – for example, Oracle’s current stance on VMware is that you have to license all the boxes in the cluster because you are giving the VM’s the capability of roving. Many would argue that the VM is never in two places at once or that this virtualisation technology is ‘hard’ because it’s technically the same as Oracle’s, so why should they consider it ‘soft’ and force the entire cluster to be covered?

Migration
Have you considered that you may need to license your installation twice whilst you have parallel running during a migration to a virtualised infrastructure? Whilst this will most likely be a new and additional spend, it may not need to be licensed in the same way as your original setup.

Who said licensing was easy? In truth, there are many nuances around the various virtualisation/isolation/partitioning technologies in use – the breadth and licensing impact of these technologies isn’t easily understood and is frequently open to interpretation depending on the operational, business and contractual context.

The 3 Vital Treatments
Drawing this 3 part summary to a close, what we are saying – that virtualisation is an abstraction of hardware from operating systems and software. Organisations consider virtualisation to save money, provide operational flexibility and prepare for future technologies. Many organisations’ virtualisation projects run into trouble when they fall foul to unfixed requirements, underestimating the technical challenge, vendor support and lock-in and unintended licensing implications.

So, our 3 Vital Treatments, to keep in mind when embarking upon virtualisation projects are:
1. Get the requirements right – what is the purpose of the project? Have you consulted experts to see if you can save money and is it the optimal way to save money?
2. A tight business case – consider all elements. Understand the potential benefits and pitfalls of your virtualisation choices especially in license terms – how do you license your new virtualisation setup and how is it different from your existing license provision?
3. Control – understand migration needs and ensure you can operate your virtualisation setup ongoing, especially from a license perspective.

The full Virtualisation Publication will offer you much more detail and insight into this paradigm and is available to download from our website.

This concludes our series on Virtualisation – if you have any questions then please do not hesitate to email me on tam.kyle@rocela.com

Oracle Unlimited License Agreements – considerations for prospective buyers Part II

Paul Bullen, Senior License Consultant Rocela

Last time we looked at the basic principles of an Oracle ULA: for an up-front license fee, you can use as much product as you like, declare your usage at the end of the agreement and then own that amount of perpetual license. This time we’ll look at bit more at specifics for considering a ULA.

How much will it cost/is it worth it? Unsurprisingly, this is a very weighty question! This next bit will sound obvious: the key consideration is how much of the unlimited product you are expecting to use, and how much that would cost if you bought ‘normal’ perpetual licenses. Doing this requires some insightful modelling—we’ll look at a relatively simple example here.

Let’s assume we are embarking on a major business-changing programme. We have a basic but large requirement for Oracle Enterprise Edition Database and the Partitioning option. For the sake of clarity, it’s easier here for us to work with a small number of products at high volumes rather than a large number of products at lower volumes, though this may be slightly less realistic.

In order to be able to consider a ULA, I need to know what the likely total cost would be for these products and the volumes. After some calculations for ‘normal’ perpetual licenses, and applying a suitably appropriate discount, I have a potential bill of £1.3m license (capex) to cover this project’s requirements. Of course, if I could get a ULA for £1m, this would be a ‘no-brainer’, otherwise I need to start ‘hedging’ my bets – £2m could still be attractive if there are other quantifiable and realistic requirements in other areas of the business. Remember, the £2m capex would attract an annual support cost, let’s say 22%, of £440k per year – but for this £440k, we could actually use well over £2m worth of licenses. So, how do I build the business case to spend the £2m upfront?

There are a large number of variables to consider here:
• Likely cost of ‘normal’ incremental purchase
• ‘Known’ versus ‘unknown’ license requirements
• How much potential is there is fully utilise the ‘Unlimited’ component of the ULA?
• What degrees of certainty are there that certain projects will go ahead and make use of the products to the level forecast?
• Is there any chance of under-utilising the ULA?
• Discount levels for incremental purchases
• How much is the ULA likely to cost? (A fairly critical question!)
• What products need to be included in the ULA? How might your Oracle strategy change over the term?
• As with all Oracle licensing, working out the licensing requirement and purchase is dependent on both technical expertise (ensuring the correct license requirement is calculated) as well as commercial and financial expertise
• An absolutely critical point about a ULA is that your support cost is based on the license fee paid up front – NOT the amount you actually use

In order to answer all these questions accurately, we’d need input from a number of people within the business, from technical to strategy to architects to commercial stakeholders.

Do not let the number of variables put you off here: think about the potential value of a ULA and the flexibility and savings it could provide your business. Oracle ULAs are an excellent way to gain control of your licensing quickly and to provide your business with a clear strategy without worrying about additional licensing costs. Remember: you pay a ‘flat fee’ to use as much of the Oracle ULA products on the agreement as you like without any impact—no change to support costs, no additional capex.

Buying a ULA is not a trivial task – it is a significant purchase which needs proficiency in understanding Oracle licensing. It is well worth having the independent expertise of Rocela’s consultants to provide insight, lead you through the process, ask all the right questions and evaluate the ULA properly. Rocela’s consultants work with complex Oracle licensing situations every day and have helped many clients understand and manage the complexities of ULAs thoroughly.

Next time we’ll look at what happens once you have a ULA, and the associated management of licenses provided by a ULA. Please feel free to leave any comments below.

Virtualisation – The Reality, not the Hype. Part II

by Tam Kyle, Senior License Consultant

It’s been a few weeks since we posted our last blog (Part I) which covered what Virtualisation is and why companies are so keen to take advantage of it. In this piece, we will discuss the sort of problems organisations encounter when virtualising and at a high level, how you can avoid these issues in the future.

Remember, at the end of this series, we will publish a fuller Virtualisation publication written by one of our Senior License Consultants, Tam Kyle – this will offer you much more detail and insight into this paradigm , how to side step the common pitfalls, its impact on licensing and the ‘3 Vital Treatments’ for Virtualisation ROI.

So, why do organisations get themselves into hot water when it comes to virtualising their environment? From our Roundtable discussion hosted in November last year, and our day to day working with large enterprise organisations, we have obtained an insight into some of the most common areas that companies fall foul of when virtualising.

• Scope creep – Part of the problem with virtualisation is that when you actually get something delivered, it’s good – people want more and they want it now. Don’t be distracted by the potential of success – by all means entertain change to your scope, but do it formally.

• Understand your needs and objectives – there are many physical implementations of virtualisation technology, but they’re not all alike; advanced implementations will bring advanced benefits, but require advanced technology. Have you considered the potential financial impact in your business case?

• Vendor Support – does the Vendor support your applications on a virtualised stack?

• Migration – Many organisations underestimate the work involved in migration. Get it wrong and you’ve got a broken application as well as a set of disgruntled users.

• License implications of migration – Checking whether your vendor is going to require you to double up licenses for the duration of the migration is important or you may unwittingly fall foul of their licensing rules potentially incurring unbudgeted expense for license non compliance

• Vendor lock-in – Your application is running on virtualised platforms and infrastructure in such an abstract manner that you don’t even know where your data is anymore. For some organisations, particularly those with sensitive data, this might not be ideal. Also, what happens if you need to change vendor?

• Ongoing control – Virtualisation isn’t a silver bullet – you don’t just walk away when it’s done. You’ve actually added a layer to your setup, so who manages the virtualisation part ongoing?

Avoiding the common issues of Virtualisation

Obviously I could go on for some time on how to avoid these common issues – for the purposes of this post, I have kept this deliberately brief. Remember that there will be a fuller publication available for down loading from our website after we have posted Part III (probably in a week’s time).

Our approach would be to understand your requirements thoroughly – document these and obtain appropriate sign off. Make sure that your business case has senior sponsorship and similar sign-off. Accommodate changes, but do it within a formal change request process.

Match your needs to a product set, or more rightly, product sets. Don’t necessarily force yourself towards one vendor – you might need to swap at some point.

Understand the footprint you are attempting to virtualise and remember, it’s unlikely that you’ll achieve 100% virtualisation. Manage expectations accordingly.

Consider the fact that there are some applications that just do not sit well with virtualisation; some are too big, have special vendor configurations and are tightly bound to hardware layers. There are other applications that you would not migrate for non-technical reasons such as company culture, 3rd party vendors and internal governance for example.

In our final blog post, we’ll look at the thorny issue of licensing impacts, with particular focus on Oracle.

Subscribe if you want to be notified of its publication.

Virtualisation – The Reality, not the hype. Part I

Tam Kyle, Senior License Consultant

So, just to remind everyone, Rocela will be posting a series of short blogs based on a Virtualisation Roundtable discussion that we hosted in November last year. This topic proved to be particularly relevant with many of our clients so much so that we thought we’d share the experience with you.

Remember, at the end of this series, we will publish a fuller Virtualisation publication written by one of our Senior License Consultants, Tam Kyle – this will offer you much more detail and insight into this paradigm, how to side step the common pitfalls, its impact on licensing and the ‘3 Vital Treatments’ for Virtualisation ROI.

As we said in our introduction post earlier this week, this piece will concentrate on (at a very high level) what Virtualisation is and why companies are so keen to take advantage of it.

So, what are we talking about when we discuss Virtualisation? The concept of Virtualisation is not a new one – IBM was one of the first to produce a type of Virtualisation years ago however this was restricted to its large expensive mainframe platforms.

Today, when you look at standard server based virtualisation technologies, what we are referring to (in very simplistic terms) is an abstraction of the hardware interface from the operating system – allowing you to visualise your Operating System (OS) as not being ‘hard wired’ to your hardware – i.e. decoupling your operating system and everything that runs on it from the physical tin. That being said, Virtualisation is no longer restricted to servers – you can virtualise storage, desktops, applications and so on. Gartner predicts that by 2018, the percentage of x86-architecture workloads running in VM’s will be a massive 86%.

In general, there are 3 main kinds of virtualisation:

• OS virtualisation
• Type 2 Hypervisors
• Type 1 Hypervisors

The type you chose/use depends on many factors – cost, functional or operational requirement, strategic vision, resource constraints, current issues and so on.

In general, the differences surround how a particular Virtualisation technology is implemented, and what it’s operational and functional capabilities and constraints are. For example, all OS Virtualisation ‘instances’ need to be of the same type, whereas Type 1 hypervisor ‘instances’ can usually run many different operating systems – you could have a Windows server running in a VM (virtual machine), alongside a Linux server in another VM. This provides more flexibility but requires typically more effort to provision, operate and support.

Let’s have a quick look at why Virtualisation is so popular with businesses today. Well, the answer is simple – time and money.

It’s a well known fact that the sheer complexity of datacentre technology and manpower required can impede an organisations ability to make change happen quickly which could affect their competitive edge in the market place. Furthermore, the ever increasing costs of power, square footage, hardware, software and internal resources means those organisations will be paying more and more to keep their IT lights on.

Virtualisation can help to solve both these problems – put simplistically, by decreasing the amount of physical hardware and space required to do the same (or a much better job), you decrease the amount of power, footfall and manpower and in turn, reduce cost. You are paying much less for more.

Virtualising also allows for much quicker and simpler provisioning – whether it’s resolving a failing server, running maintenance patching or accommodating new applications. It’s the dream scenario every IT or Datacentre Manager dreams of – efficient, resilient with minimal ‘hands on’ management.

You might be saying to yourself ‘I know all this’, however from our experience in helping clients resolve Oracle licensing issues, what is less understood is why many Virtualisation projects go wrong, particularly when it comes to license compliance. In our next blog post, we’ll take a look at some of the common issues including the impact on licensing.

Subscribe if you want to be notified of its publication.

Virtualisation – The Reality, not the hype – An Introduction

by Tam Kyle, Senior License Consultant

In November last year, Rocela hosted a Roundtable on Virtualisation which discussed the challenges of virtualising and the ‘3 Vital Treatments’ to ensure business case ROI.

It was obvious from the peer to peer group discussion that organisations are giving Virtualisation serious consideration in an attempt to save cost and improve efficiency and are therefore, keen to side step some of the many challenges faced when virtualising their IT environments.

In this series of blog posts, we will discuss Virtualisation at a reasonably high level, covering elements such as;

• What Virtualisation means.
• Why organisations are keen to virtualise.
• Why Virtualisation projects go wrong.
• Some advise on avoiding the Virtualisation pitfalls.
• Licensing impacts, particularly with Oracle licensing.
• The 3 Vital Treatments for getting Virtualisation right!

At the end of the blog series, we will publish a 5 page Virtualisation publication written by Tam Kyle, Rocela Senior License Consultant, (which will be downloadable from our website) and will provide a full insight into the typical pitfalls of Virtualisation, some tips on how to avoid them and culminate on the ‘3 Vital Treatments’ to ensure business case ROI.

Part I, which will be published in a few days, will cover what Virtualisation is and why organisations are so keen to take advantage of this technology. Make sure you subscribe to receive notification of its publication.

BI Publisher Licensing considerations

By Paul Bullen, Senior License Consultant for Rocela

Recently we’ve heard about the many advantages and considerations of using BI/XML Publisher against Oracle E-Business Suite. Like many Oracle products, this provides some very powerful functionality which once mastered can revolutionise your use of applications. However, this functionality comes at a cost. As part of any (correctly) licensed Oracle E-Business Suite applications, you receive a restricted use license for Business Intelligence Publisher. What does this mean? Well, unfortunately the restrictions really are quite significant. Looking at standard terms and conditions, you are allowed to use Business Intelligence Publisher to publish and/or view:

1)      Shipped Oracle Business Intelligence Publisher reports: you are allowed to make changes to the layout of these reports

2)      Shipped or newly created Oracle Business Intelligence Publisher reports that are modified to access data from existing Oracle E-Business Suite Applications schemas that have not been customized

So, you can use the shipped reports and change their layout. Or you can create new reports which access non-customised schemas. In order to gain most business benefit from the BI Publisher, you’re probably going to want to create your own reports or query against schemas which have customisations.

Oracle provide further clarification:

Full use of Business Intelligence Publisher is required if any shipped, modified or newly created Oracle Business Intelligence Publisher report:

1)      Accesses data from a non-Oracle E-Business Suite Applications data source, or

2)      Accesses data from a new schema within the Oracle E-Business Suite Applications that is not shipped by Oracle, or

3)       Accesses data from a modified Oracle E-Business Suite Applications schema (e.g., by adding columns to an existing table).

Given how BI Publisher is Oracle’s strategic enterprise reporting tool, and may well become yours, it is imperative that you understand how you are licensed for using it. As a separately licensed product, it is available in either Named User Plus (£308 each, list price, minimum of 50) processor metric (nearly £31k per processor, list price), or Employee metrics.

The above restrictions are standard terms and conditions, they do vary and so it is worth checking your license documentation, bearing in mind your license may have been purchased before BI Publisher was released. If you are in any doubt, contact Rocela!

XML (BI) Publisher fit to ‘burst’!

By Andrew Archibald, Senior Consultant Rocela

As a curious technologist, I have recently revisited the functionality of emailing documents from Oracle E-Business to multiple recipients; a functionality called ‘bursting’ in Oracle E-Business language. I have used BI Publisher to ‘burst’ PDF’s out of Oracle E-Business R12 and save them to the server ready for printing – a relatively simple process using the web services available with BI Publisher.

However, when using Oracle E-Business R11 and XML Publisher, this method is not as straightforward and requires additional coding. Happily, there is a great deal of solid reference material out there for this (both Oracle documents and blog postings) which details the steps required for ‘bursting’ in XML Publisher.

One of the best features of XML Publisher is the ease in which you can link to Oracle E-Business Suite – if you set the code of the concurrent request to the same name as the XML Publisher data definition template, they automatically link together. My colleague Kenny Miller mentioned this in his recent post.

For now, I’m going to consider some of the “gotcha’s” when implementing ‘bursting’ functionality.

Building your RTF document, beware!

Oracle BI Publisher desktop is a great tool and makes it easy to create templates. The plug-in allows you to import demo XML and then create groupings, tables and fields on templates, but there are a couple of things that you need to watch out for.

Firstly, when you insert a new field into the template, BI Publisher creates a Word field and then attaches the BI Publisher options. The problem this can cause is around the values within the ‘advanced’ properties (right click on the field and select ‘BI Publisher’). These must match up with Word’s ‘help’ properties for that item. If they are different then the document will fail when BI Publisher tries to merge the XML and the template.

Secondly, if you are looking to ‘burst’ this document and also to store all the output as one document, you need to create a grouping which will encase your template and fields (don’t worry about headers and footers on the RTF document).

Be aware if you have a grouping on a lower set of data within your document; for example you have your invoice header details then displaying the invoice lines, the outer grouping may have an effect on the whole document. Always remember my first point about Word’s ‘help’ properties; these are easily reset by Word which will break your document. So, always check them before uploading to BI Publisher!

Building your ‘bursting’ file

Best tip is to start small, only build small components and start with small amounts of data. Don’t think that because the individual file generation works, that it will also work when it’s called a ‘bursting event’.

The log files are stored in the following places to help diagnose the issue. Log files are located in comn/util/java/jdk1.6.0_22/jre/lib for any BI Publisher logs.

The ‘bursting’ file takes an XML path as a parameter (tag <xapi:request select) which is used to split the data in the XML file output from the concurrent request and generate separate documents.

Ensure that the XML in the ‘bursting’ file is consistent with the structure of the output from the concurrent request. To view what is generated by Oracle E-Business, run the concurrent request to output the data as XML. If the XML path is incorrect you will notice that your document will only show the first record in your XML output.

These are just some of the features which you should watch out for and hopefully this will save you a few headaches! Just one more potential headache before you ‘burst’: it’s worth remembering that BI Publisher is a separately licensed Oracle product and although a restricted use license is included with Oracle E-Business Suite, it only allows certain restrictive usage of the product. One of my License Optimisation colleagues will write a blog about BI Publisher licensing soon. In the meantime, assuming you are licensed correctly, happy ‘bursting’!