Bursting in One Step from R12.2: Users in the Dark on Request Status

In the latest release of EBS R12.2, Oracle has introduced the ability to burst in a single concurrent request. Although we predicted this was coming, we weren’t sure what it would mean for users and support admins. What we have found is that the new feature actually creates a worse experience for the end user and as a result, the business as a whole.

Here is how it works: Oracle has added a check box to the Submit Request form and users can select whether they want the document to be burst and away it goes (you still have to setup your bursting control file and all that fun stuff). A single concurrent request is kicked off and the Output Post Processor takes it from there and bursts the data.

Unfortunately, in tinkering with this functionality I found a couple things that were concerning:

1. Oracle’s Bursting Status Report that we’ve all come to know and love does not get generated. Instead, status information is actually posted in the logfile for the request itself. Prior to this change the Bursting Status report used to look like this, which provided some insight:

Now…  you just get this information buried in the log:

— BURSTING:
— Bursting results —

KEY: PO# 6574
OUTPUT_TYPE: pdf
DELIVERY: email
OUTPUT: /d01/oracle/VIS/fs1/inst/apps/VIS_vm-dev-1221/appltmp/091613_140248305/xdo1_PO# 6574_2.pdf
STATUS: success

KEY: PO# 6575
OUTPUT_TYPE: pdf
DELIVERY: email
OUTPUT: /d01/oracle/VIS/fs1/inst/apps/VIS_vm-dev-1221/appltmp/091613_140248305/xdo1_PO# 6575_6.pdf
STATUS: success

+—————————————+

Ugh…Unless your end users read log files, they now have less hope of figuring out the status of their documents without calling an administrator, or worse, hearing that it didn’t arrive from the intended recipient. How is that good for your users? Note that if you want to keep the bursting status report around, you can always go back to submitting two concurrent programs! Also note that as always, the status of the document is actually the status of BIP handing off the data to the 3rd party delivery mechanism, not the actual status of the report that was sent. For that, you’d need a product like AventX which lets end users drill down and manage individual documents on their own.

2. The second concern is that depending on the amount of data that you are bursting, the concurrent request can timeout waiting on the Output Post Processor and complete with a warning. At the same time, the bursting is still happening in the background and NO status is returned to a user.

For example, I submitted 3500 POs in a batch to be burst. According to the logfile, post processing started at 10:18a and the concurrent manager timed out waiting for the post processor to complete at 10:25a.* The timeout is fine and normal, and I’m certain can be tweaked. The concerning thing is that even though the timeout occurred, the bursting did not stop! It’s currently 2:15p and I’m still getting emails from the bursting program. Now here’s the real problem: my users have no clue that the bursting program is still running and have no way to get status and will likely resubmit and RESEND the data to the end recipient. Imagine if this was a PO and the order was fulfilled twice? These “little things” make it clear that Oracle wasn’t developing with the daily routine of users in mind and explains why we hear stories from users that their Procurement team or AR team doesn’t “trust” the black hole that is delivery from EBS.

So as you can see, Oracle may have taken one step forward by consolidating back end processing of delivery requests, but took two steps backward in delivering end user experience.

(*note as of 10:25a when the concurrent request timed out, only 48 documents had been delivered. The machine this is running on is not the fastest, but I would expect that the timeout parameter will need to be tweaked across the board).

AventX provides end users with the ability to view delivery status and manage documents from within Oracle – no admin required! Want to know more about how to schedule, burst, and deliver critical invoices, POs, and other documents from Oracle EBS? Check out AventX.