With a running BIP Publisher server and tested integration, we can start looking at migrating Actuate reports to the BIP Publisher format.

Some key facts to recall from previous posts:

1. Actuate uses COM to talk to Siebel. This means Report objects in Tools, .ROL files and ssiebel.bas
2. BIP uses Web Services. This mean Integration Objects, SOAP messages and XML
3. Actuate uses it’s own .ROD file format to store report definitions, designed in the Actuate eReport Designer application
4. BIP uses a simple .RTF file format to represent reports designed in Microsoft Word, using the BI Publisher Desktop plug in

You are probably thinking at this point – Report Migration Tool. It’s true that Oracle have made available a migration tool through My Oracle Support (Patch ID 8968224). The tool will attempt to create IOs from your Report objects and .RTF files from your .ROD / .BAS files. In practice, I’ve found it to be buggy and the results less than satisfactory. The remainder of this post assumes you’ll want to re-do your reports manually but please feel free to give the tool a try and see if it works for you.

The steps for report migration involve migrating the data structure from Report objects to Integration Objects then migrating the report design from Actuate (ROD) to BIP (RTF). Let’s start with the data feed. Roughly, this translates to the following steps:

1. Locate the Report object and note the underlying BC and fields
2. In the corresponding View Report object, note the underlying BO. I realise that there can be more than one view associated with one report, and we’ll cover that scenario below.
3. Create an Integration Object, using the Tools wizard, mapping from the BO, BC and fields of the Report object.
4. If you want to use a Primary MVF, select the top level object in the wizard. If you want a repeating group across an MVL, select the child object in the wizard
5. Check in and deploy to the server via Tools (Deploy to Runtime Database)
6. Navigate to Site Map > Administration – BIP Reports > Sample Data File Generation and generate sample XML for your IOs

It’s essentially that simple: BIP will use this IO to pull data out of the object layer using EAI via a Web Service call.

Migrating the report design itself is a less straight forward process but still not overly complex. Here are the steps that I would suggest:

1. Open your Actuate report design in eReport Designer. Not only can you view the report layout, you can drill down into the Data Stream to pick out any modifications in the fetch or layout code
2. Open Word, go to Add Ins and check that the Oracle BI Publisher toolbar is visible
3. Select the Data > Load XML Data menu to load the sample XML file that you generated previously
4. Replicate your layout and design in the Word document
5. Use the Insert > Field menu to add your field label placeholders into the report document
6. Use the Repeating Group and Table Wizard menu items to create repeating groups for parent, child and grandchild relationships
7. Use the BIP Publisher User Guide, installed in the Start Menu, to translate your Actuate code to BIP code
8. Use Preview to see how the report looks and tweak appropriately
9. When you are happy, use the Tools > Translate Template > Extract Text menu item to generate the .XLF file that Siebel requires
10. Upload to Siebel via Report Template Registration, assign to a view via View Association and you’re done!

Clearly, I’ve vastly over simplified the steps to migrate any custom code and layout in your Actuate Reports. However, BIP has a powerful language construct that can be embedded in your documents to provide any custom functionality that you might have. Check the BIP user guide for more information.

Please feel free to post if there are specific steps that are troubling you or any particular functionality that you are trying to migrate across that is causing you grief.

Following on from our previous discussion around installing and setting up BIP, I thought I’d drop in a quick article to talk briefly about additional Siebel server and application configuration. We’ll start off with some useful information:

As you know, Actuate Reports were defined in Tools and associated directly with Views within the Repository: Report and View Report object types should be familiar. Tools generated a Report Library (ROL) file which would be incorporated into the Report Design (ROD) to feed data into the report. The View definition, along with the Report object definition, then allowed a user to select and run a report. Unsurprisingly, things are different in Siebel 8.1!

First of all, the only work done in Tools is to specify Integration Objects. That’s it. When it comes to deploying reports, things are a lot easier than before! Take a look at the Administration – BIP Reports screen: here you’ll find where to create new Report definitions (think Report objects in 7) and associate them to Views (thing View Report objects in 7). There are also views which allow you to generate sample data to assist with developing reports and a view to purge completed report items. The ‘Views’ view is self explanatory and is a lot nicer than the old Tools mechanism: associate the Report here and users will immediately see it in the ‘Reports’ icon menu.

An important view in this screen is the Report Template Registration screen. Once you have the server up and running, as per the previous post, this is where you’ll need to come to progress further.

Much like Actuate, BIP hold report designs independently of Siebel. In the case of BIP, RTF files represent the report designs. Having got everything else working, you must now populate the BIP repository with the standard Siebel Report Designs. From within this view, highlight the reports to upload and click the ‘Upload Files’ button. Log in to the BIP Portal and have a look under Shared Folders > SiebelCRMReports: you should see the report objects appearing here as they are uploaded from Siebel.

You should now be able to run vanilla reports from the Thin Client in Siebel 8.1: navigate to an appropriate view, click the ‘Reports’ icon and you’ll see available reports under the ——- BI Publisher Reports ——- header.

Common problems at this point again seem to relate to the Web Service definitions and configuration and the BIP Security Model config. See the previous post for a link to an article on MOS that covers these off. Also remember that the ‘XMLPReportServerxxx_xxxxxx’ log file is your friend!

As ever, please feel free to post about any issues you have or have resolved.

Next time, I’m going to look into report design within BIP and how to upload and execute custom reports.

A very quick post today to highlight a My Oracle Support article that should be your first port of call for diagnosing and resolving Siebel BIP problems:

Troubleshooting problems with the Siebel BI Publisher integration [ID 1051319.1]

I’d highly recommend that anyone looking to implement BIP, or migrate from Actuate, have this article to hand.

In the first of my Reporting articles, I’ll discuss some of the architectural changes that have taken place in the move from Actuate to BI Publisher (hereafter referred to as BIP). With Siebel 8.1.1.2 the recommended version of BIP is 10.1.3.4.1. You’ll need this if you want to use report scheduling from within Siebel.

Typically, the Actuate Report Server application server is hosted in a load balanced configuration, with one master server and one slave. Internal Actuate load balancing handled the shared encyclopedia and balancing of requests. Siebel required the configuration of a virtual host (rshost) , telling it where to find the Report Server, and a component parameter, Actuate Server Connect String, telling the component the Siebel connect string to use to connect to an Object Manager to retrieve data. As you may recall, Actuate uses the COM Data Server to pull data through the Business Object layer.

Things are not too different in BIP. Server setup is straightforward and load balancing and clustering can be configured. Refer to this Oracle document for more information. When it comes to actual installation, it is essential that you follow the updated installation guide in Siebel Bookshelf. The original 8.1.1 guide misses a number of critical set up steps. I have a customized, step by step installation guide to hand – please email me if you’d like a copy.

Configuration for Siebel is a little more complex. Siebel now has a dedicated ‘XMLP Report Server’ component which you’ll need to license, enable and configure. BIP exposes Web Services that allow requesting and scheduling of reports, while Siebel exposes Web Services to allow BIP to query and retrieve data through EAI. As such, various entry points and URLs must be configured. Again, steps are documented in Bookshelf, so I won’t list them here. Provided you following every step and subsection in the Reports Guide, you should not have any problems. Resist the temptation to stride ahead and skip a section!

A number of things to check if it doesn’t work first time:

I’m conscious that I’ve not gone into a massive amount of detail around this area, but bookshelf and MOS combined should be enough to get things running. If you have any specific issues, please feel free to post.

Having recently upgraded the Actuate reporting solution in a client’s 7.8 SIA implementation to 8.1.1.2, I thought I’d share my thoughts. The move from Actuate to BI Publisher (BIP) is not as terrifying as it may first appear, but there are some gotchas in there that you need to be prepared for. In the next series of articles, I’ll have a look into what has changed and what you need to do to succesfully migrate across to the new platform. Be aware that 8.1.1.2 has delivered a bunch of stuff around integration with BIP: if you’re looking to upgrade, 8.1.1.2 (or 8.2 if you’re Public Sector) is the way to go. Also be aware that Oracle has withdrawn support for the Actuate Report Adapter that they were offering with 8.1: it’s no longer available for download, so it’s going to have to be BIP all the way!

Here’s what I’m going to cover over the coming weeks:

1. Architecture - what’s changed and how to set up BIP. We’ll briefly touch on high availability and load balancing, since you’re likely to be migrating within an HA production architecture anyway
2. Application and Server Configuration – there’s a fair bit of setup involved in getting BIP working in your Siebel environment. A number of patches and MOS supplied SIFs will be required if you want to replicate some of the more complex functionality from previous versions. There’s also some configuration required around Web Services, authentication and Java class libraries. Be prepared to dig through bookshelf in conjunction with MOS and ad-hoc Oracle documentation updates
3. Report Migration – moving from Actuate Report Design (.rod) files is not as tough as it may seem. Where Actuate used the COM control to pull data through the BO layer, BIP uses Web Services and Integration Objects to pull data through EAI. BIP also provides a number of features within it’s Word plugin tool to deliver comlex report content, with a Siebel provided Java library of functions topping off the tools to migrate reports

It can be a daunting prospect migrating to a different product, especially when you have something tightly integrated into your environment and business processes. On this site, we use calls to Actuate from Workflow to generate documentation as part of several different business processes. We had the ‘Report Business Service’ to help us in the old days, but Oracle have yet seen fit to provide equivalent functionality for BIP. However, later on we’ll see how to overcome these limitations and deliver like for like functionality.