Oracle E-Business Suite printing made easy with Pasta!

by Kenny Miller, Principal Consultant for Rocela

This one is for my fellow EBS veterans who’ve spent more time than they’d like to admit fiddling with application printer settings. Maybe, like me, you’ve been aware of Pasta but have been too busy to find out what it is and how it works.

Necessity is indeed the mother of all invention so, when recently faced with a challenging printing requirement, I was forced to find out all about Pasta. I liked what I found, so I thought I’d share my experiences with you.

The Requirement

My client is upgrading from R11 to R12. In R11, they only needed to print text output directly from the concurrent manager. However R12 comes with many more standard XML Publisher reports, so they now have a requirement to print PDF output.

My client also has hundreds of printers, from many different manufacturers and of different vintages! More specifically the requirement was:

1) Print all text and PDF output directly from the concurrent manager.
2) Print in PCL because:
a.  Not all printers support PostScript.
b.  Not all operating system print queues are enabled for PostScript, even for printers that actually do support it.
3) Minimise the amount of application set-up changes required.

So what is Pasta?

The following is taken from the System Administrator’s Configuration Guide:

“Pasta is an Oracle E-Business Suite utility that converts text report files to PostScript and also enables the printing of custom PostScript reports from Oracle E-Business Suite. The reports can then be directed to any PostScript printer.

Setting up your system to use Pasta is much simpler than the standard Oracle E-Business Suite printer setup procedure. The Printer Type, Printer Driver, and SRW driver files are provided. The only setup required to begin printing is the registration of the printer with Oracle E-Business Suite.

Many printing options can be defined using the Pasta configuration file (pasta.cfg). You no longer need to maintain multiple drivers and styles for each printer.

Pasta is provided as an executable named FNDPSTAX.”

I make no apology for copying this – it’s actually a good summary of Pasta. However the first paragraph only mentions PostScript i.e. converting text to PostScript, printing custom PostScript reports to PostScript printers etc. Mere mortals may have given up at this point, thinking Pasta is only about PostScript and isn’t able to do PCL. Yours truly is made of sterner stuff, and decided to have a look “under the hood” to find out what Pasta is really capable of.

PostScript or PCL?

Well, “out-of-the-box” Pasta actually does neither! All it’ll do is print text!

However, the Pasta configuration file does provide a “pre-processing” option, which can invoke any executable that supports an input file and an output file. Therefore, executables such as pdftops and acroread can be used to convert PDF’s to PostScript, or Ghostscript can be used to convert PDF’s to PCL!

The default configuration file is $FND_TOP/resource/pasta.cfg and by adding the following line to this file, PCL printing is enabled for both text and PDF output:

preprocess=gs -q -dNOPAUSE -dBATCH -sDEVICE=pxlcolor \

-dNORANGEPAGESIZE -sOutputFile={outfile} {infile}

In summary, this is using the Ghostscript executable (gs) to convert the input file to PCL. The device switch of pxlcolor tells Ghostscript to convert to colour output in PCL XL format. PCL XL (also known as PXL) is part of PCL version 6 which was released by HP in 1996, and should therefore be supported by all modern printers.

Problem Solved

My client is now able to print text and PDF output in a variety of different print styles, to printers from different manufacturers. To do this, all that was required was the following:

1) The change to pasta.cfg described above.
2) Changing the printer type to the seeded:
–PASTA Universal Printer Type
3) Bounce the concurrent manager.

Sounds too easy!

It would be very time-consuming to test all combinations of print styles and printer types; therefore you need to be realistic enough to expect the occasional anomaly. Pasta caters for exceptions by providing:

1) Printer specific configuration files.
2) Printer Driver specific configuration files which can be specified in the arguments for the Printer Driver.
3) A combination of Printer and Printer Driver specific configuration files!

If you’re able to successfully print output from the command line, then Pasta will be able print the same output from the concurrent manager.

Summary

I’ve found Pasta powerful but simple to use. If you already know your way round EBS printer set-ups then you’ll take to Pasta like a duck-to-water. Even if you don’t, it’s well worth investing some time to better understand it. It’ll be well worth it.

Advertisements

Part II – SAM for Oracle – discovery tools are only half the battle, maybe a quarter, even …

By Tam Kyle, Senior License Consultant

So, at the end of my previous post on discovery tools, we had reached the point where you were probably going blind on a very large spreadsheet only to discover that you are still no further forward in establishing your compliance position.  In this post, I’ll explain why.

Ask yourself, how can you know if you are compliant based on usage information only?  What about your entitlement – what are you actually legally allowed to use?

Where discovery tools fall short is knowing what you are entitled to, i.e. what it says in your contract with Oracle.  Ah! This sounds like a job for the Procurement Department.  If you are lucky, you have a central Procurement Department that buys everything from staplers to Datacenters and therefore, you are more likely to strike lucky with whoever is responsible for buying all of the company’s software.

If however, you have decentralized purchasing and have Oracle users around the world, where on earth do you start?  Let’s assume for one second that you have managed to obtain what the procurement department thinks is all the correct Oracle contracts for everything they have ever bought over the last 5 years.  Firstly, do you really have all the contracts and secondly, do you actually understand what the contract is telling you?  Have contracts been amended, have products been novated – can they even be used now?

Read more of this post

One small step for man, one giant leap for Web ADI

by Kenny Miller, Principal Consultant for Rocela

I recently blogged about ”BI Publisher becoming every accountant’s best friend”. However, as we all know, it’s difficult to keep an accountant happy for long. They’ll likely soon be asking an awkward question of their new best buddy:

“OK, I can see that BI Publisher is great for downloading data from Oracle EBS (E-Business Suite) straight into Excel, but can I do it the other way round? Can I upload data from Excel into Oracle EBS?”

BI Publisher is a reporting tool. It can’t upload data into Oracle EBS. So what other options are available?

Many of us will have developed custom CSV interfaces, where users create data in Excel, save it as a CSV file, which they somehow transfer to the Oracle EBS server, before SQL*Loader (or External Tables, if you’ve “moved with the times”) populates the data into a temporary table where finally it’s processed by a custom program using a standard API or interface. A convoluted solution which has its problems:

  • Having so many “moving parts” means there are a number of different ways for the whole thing to fall over in a crumpled heap (technical term, meaning to “perform sub-optimally”).
  • It’s difficult in Excel to validate the data to be accurate and relevant, without resorting to something complicated like ODBC or Visual Basic. For example, does a cost centre value entered in Excel actually exist in Oracle EBS, is an accounting date in an open period etc?

If you’re interested enough to still be reading then I expect you already know all about Client and Web ADI in Oracle EBS (for those of you still on 11i, be aware that it is Web ADI only in R12). Application Desktop Integrator (ADI) is Oracle’s standard tool for connecting Oracle EBS with MS Office tools e.g. HR letter generation using MS Word, and uploading GL journals using MS Excel.

The problem with ADI had always been that only Oracle could decide what you used it for. There was no supported way to create your own ADI document for something that Oracle hadn’t already provided. HR users have always “felt the love” from Oracle who provided them with numerous standard ADI documents. Unfortunately most of our accountant friends missed out on an invite to the ADI party. Oracle doesn’t provide even a single standard ADI document for either Payables or Receivables, so you won’t be using ADI to load your supplier invoices or your cash receipts.

However, this has all now changed! Available from R12.1.2 onwards is the “Desktop Integration Framework” (DIF)! Finally there is a supported way of creating custom ADI documents, allowing data to be properly validated and processed through any interface or API into Oracle EBS. Only time will tell if this is a “giant leap for Web ADI” but it’s certainly a welcome new option to have available, and one I thought you’d like to know about it.

If you want to learn more then I’d recommend the following material:

  • Oracle note 807319.1 which lists all the Transfer of Information (TOI) content for R12.1. Search the note for “Implement and Use Oracle E-Business Suite Desktop Integration Framework” and you’ll find a very informative eSeminar.
  • The “Oracle E-Business Suite Desktop Integration Framework Developer’s Guide” in the documentation library, which for R12.1.3 is available here.

I’m hoping to use DIF soon to develop a custom ADI document for a client. I’ll blog again once I’ve done so – I’m sure you’d like to know if the reality lives up to the hype. In the meantime, if you have any experiences with DIF you’d like to share, then please let me know.

 

 

Top 5 Tips for upgrading customisations to R12

by Kenny Miller, Principal Consultant for Rocela

My colleague Ray Brown’s recent blog “Top 5 Tips for Oracle R12 Upgrade Success”  highlighted how the cost of upgrading customisations can be a significant proportion of the total cost of an R12 upgrade project.

This got me thinking about my own experiences with R12 upgrades. I doubt you’ll be surprised to learn that there is no “silver bullet” to provide an easy path for upgrading your customisations. There is no substitute for hard-work, and for approaching this work in a sensible and structured manner.

The key to success is having the correct resources available at the appropriate time in the project life-cycle, and accepting that considerable effort will be required from these resources. To help understand this better, I’ve put together my top 5 tips for upgrading customisations to R12:

1. Prepare

It’ll really help if you have some knowledge of R12. You can’t beat “hands-on” when it comes to learning, so consider installing a R12 Vision demo instance. Make sure it’s fully patched up, to get all the latest functionality and bug fixes.

Business and Super Users: Your business needs to understand how R12 functions; what’s new, what’s changed etc. This task is really part of the wider R12 project but, as we’ll see later, this knowledge is important when you review your current customisations.

I’d recommend starting with Oracle note 403349.1 which details all the Transfer of Information (TOI) content which Oracle has provided for R12. Another good resource is the Documentation Library, which for R12.1.3 is available here.

This is where having a R12 demo instance will help – it’s “play area” where you can try things out without the risk of hurting yourself!

Developers: Have a look at the usual suspects in the Documentation Library, but be aware that Oracle has started to move interface/API documentation to the “Integration Repository”. In R12, this is available in the “Integrated SOA Gateway” responsibility (see Oracle note 462586.1 for more details).

I’d also recommend the following material:

2. Quantify

If you haven’t already got one, then you’re going to need a list of all your customisations. Don’t under-estimate how long this might take to prepare – there are so many different ways to customise EBS, not all of which are obvious and easy to find. Most “mature” EBS systems have many hundreds of customisations.

I’ve done this for quite a few of our customer recently and, despite knowing what to look for, it still takes me between 3 and 5 days to complete.

3. Review

Eliminate: The easiest, and therefore cheapest, way to upgrade customisations to R12 is not to upgrade them at all! Eliminate any customisations that the business no longer needs, or those that can be replaced with new standard functionality.

This is why it’s so helpful that your business/super users “immerse” themselves in R12. Only with this knowledge can they properly understand the requirements for R12 customisation. If your organisation doesn’t feel confident enough to do this, then seek assistance. You really should avoid upgrading redundant customisations.

Prioritise: What is business-critical? What is not needed until the next year-end etc? It makes sense to focus first on the most important customisations.

4. Plan

To plan properly, you need to know how much effort is going to be required. This is a challenging task, even for those of us that have considerable experience with R12. You need to know R12 well before you can attempt this with any degree of accuracy.

It’s not just about estimating either – it’s also about establishing your approach and identifying the skillsets needed. For example, your custom Sales Invoice program is likely to upgrade with little or no rework, but your custom Payables BACS program will need to be completely redeveloped using BI Publisher.

R12 is not as different from R11 as you’d think, but it is different. The “devil is in the detail” and in this case the “detail” is the differences between R11 and R12.

5. Test

If ever there was a time to believe the old adage about “never being able to test enough” then this is it. Test, test, then test again.

Be comprehensive with your testing. If you use the Transaction Import interface then create invoices both for existing customers upgraded from R11, and with new customers created in R12. Test your redeveloped BACS program by paying invoices created in R11 and R12. I’m sure you get the idea.

Also be realistic with your testing. If you typically import 100,000 invoices at the month-end, then don’t test with 10,000 and assume that 100,000 will take 10 times longer.

Finally, be pragmatic enough to accept that no matter how much testing you do, there will always be something you miss. It’s called “sod’s law”.

Summary

Upgrading your customisations to R12 will be a challenge, but hopefully the tips above should help provide some direction. Be prepared to work hard, and get external assistance if required. Plenty of others have been there before you, so don’t be hesitate to take advantage of this experience.

Finally, we have just recently added a new case study to our website on Oracle R12 Upgrades – you can read this here.  We hope you find it interesting.

Have you recently upgraded from Oracle E-Business R11 to R12 and find yourself unable to launch APEX from the responsibility menu?

By Andrew Archibald, Senior Consultant for Rocela

With many of our customers upgrading their Oracle E-Business Suite from R11 to R12, some have found an issue with launching APEX applications from the custom responsibilities. When users select the ‘responsibility’ to launch and log them into APEX they come across a ‘page cannot be displayed’ error.

So what’s happened to cause this?

Well, Oracle have decided to stop supporting launching mod/plsql functions in R12 which means the nice and easy way of integrating APEX with Oracle E-Business is currently ‘out the window’.  You now have to launch APEX using another method – the recommended process being using a JSP page.

How do we fix this?

First off there is a great Oracle white paper written by Rod West ,
The Fast Way to Extend the Oracle E-Business Suite, for R12.1.2 or lower which details how to integrate APEX with Oracle E-Business Suite both R11 and R12. This document is fantastic if you are starting from scratch and will get you up and running in no time (please check out this post though).

For release R12.1.3, a new document was released; Extending Oracle E-Business Suite Release 12 using Oracle Application Express where Oracle have supplied a JSP as part of the install which you can use to launch your APEX applications.

So why is this an issue?

The problem is losing all your hard work of integrating APEX with Oracle E-Business Suite for R11.  Setting up your own redirections to the correct page or using your own custom cookies are only a few of the custom developments you might have completed.

The JSP page is simple and will allow you to redirect to APEX.  This is wonderful as you can still integrate APEX with Oracle E-Business Suite but with a couple of simple changes, you can keep all your existing code and only have to change setup marginally.

What do you need to do?

First off for all versions of R12 you need to use the JSP page and have followed all the steps in the white paper The Fast Way to Extend the Oracle E-Business Suite . The section you need to change is ‘the building of the url’. This is to allow for the form function to pass the name of the publically accessible procedure created in R11 to launch APEX.

Replace the existing section in the JSP page to the code below. The code is taking the value passed in the parameter and also fetching the profile option value for the APEX url.

<%
String p_params = request.getParameter(“params”);
p_params = (p_params==null ? “” : p_params);
AppsEnvironmentStore m_env = (AppsEnvironmentStore) ctx.getEnvStore();
try {
String l_launcher = ctx.getProfileStore().getProfile(“APEX_HTTP_SERVER”);
l_launcher = l_launcher + “/” + p_params;
%>

Next, the form function needs to change, so instead of calling the publically accessible procedure in the HTML, call the section of the form function you will pass in LaunchApex.jsp, change the properties to SSWA JSP function and then in the parameters section enter params=apps.MYAPEXLAUNCHPROCEDURE

Conclusion

With Oracle R12, a new step has been added into integrating APEX with Oracle E-Business Suite but hopefully this step will now provide little trouble and allow you to keep on developing great APEX applications.

Top 5 Tips for Oracle R12 Upgrade Success

by Ray Brown, Rocela Project Manager

As one of Rocela’s Project Managers who is currently managing several clients through their Oracle R12 upgrade, I have developed a deep understanding of the challenges and successes, pitfalls and quick wins of an Oracle R12 Upgrade.

Making the decision to upgrade is an important step and can truly enhance how you operate and perform as a business.  Get the implementation of this wrong and you will endure business disruption, process inefficiency and low return on investment.

So, what can you do to make the transition go smoothly? Well, there are a number of elements you need to take into account.

Here are my top tips that should help you through the process.

1. Planning

Plan! Plan! Plan!

Yes, I know we all do it, but you need to ensure you create a sound plan and get buy-in from all areas of the business. Having a ‘project kick-off’ meeting to gather maximum momentum from the beginning is a good starting point.

Ensure plans cover all the following areas:

Hardware delivery times (if new hardware is being deployed): Many an upgrade project has been delayed from the start when hardware wasn’t commissioned in time

Internal IT resources:  Even if the upgrade is making use of existing hardware IT support will still be required to install new operating system patches and packages, to make disk space available and to secure backups at key points in the projects

Software release: Agree up-front exactly what version will be installed and to what patching level. Unless the version has just been released by Oracle then it’s certain to be the case that various later security patches, roll-ups and key bug fixes will be available and should be applied up-front to reduce the likelihood of errors being encountered during testing

External resource:  If upgrading using consulting support then make sure that you understand clearly the scope of the services they are providing and ensure that any remaining tasks are assigned to internal resources.

Internal resource: Planning internal resource for an upgrade can be one of the most difficult takes because it usually has to be fitted around users day-to-day work commitments and take into account holidays and busy periods such as month or year-ends. Clearly planning what internal resource is required and when makes securing the resource from the relevant management in the business much easier.

 2. Licensing 

Upgrading Oracle E-Business Suite introduces opportunities and risks with regard to Oracle software licensing. It’s an opportunity to review and streamline the hardware architecture, with a possible reduction in technology licensing.

It’s also a point where customers overlook the licensing implication of changes they make, which can lead to nasty (and expensive) surprises if audited by Oracle. In particular if you’re deploying new hardware then make sure that you don’t exceed your technology licensing (bearing in mind such complications as processor minimums and core multipliers) and don’t assume that just because you’re reducing the overall number of processors deployed that you can’t still get problems.

Also be careful when making use of new technologies (such as BI Publisher) or Oracle E-Business Suite modules that you’re not getting into a situation where additional licenses need to be purchased. Oracle licensing is a complicated area so if unsure then take professional advice!

3. Environment

I would always recommend that the correct level of hardware is available during the upgrade project – duration can vary from project to project (3 – 12 months). It’s likely that additional instances will be required as 11.5.10 and R12 systems will be running simultaneously.

So, consider sourcing additional hardware (even temporarily if required) to accommodate this. Before starting the project it’s essential to do an environment review to confirm that the hardware you have will cope both with the project and with eventual production use of R12. Creating an environment plan as part of the project kick-off is a good idea.

4. Customisations

There may be far more customisations in your system than you are aware of. A good idea is to thoroughly review the customisations in advance and carefully question whether they are required.

Consider whether there is functionality within in Oracle R12 which supersedes these customisations and review your existing documentation to understand what customisations you have. Unfortunately in some cases, this can highlight the lack of documentation!

Conducting this review prior to the upgrade ensures that you have reasonable customisation estimates in place as input to your plan. Don’t be surprised if the cost of upgrading customisations is a significant proportion of the overall project costs.

5. Testing

It is of upmost importance to ensure the appropriate amounts of testing are scheduled in your project plan. Utilise previous scripts if they are available (if they’re not then plan in the creation of test scripts early in the project) and get the business units involved in testing.

Have a team ready to do some high level testing of key processes immediately following the 1st iteration upgrade. Check standard screens and reports still perform in the same manner as in your current release and there is no impact on performance.

How can you make it easier?

Upgrading is always a substantial project, but talking to an experienced Oracle specialist or taking into account some of the tips above can make the difference between a successful project with return on investment and a failed project requiring unbudgeted cost to resolve.

We have just recently added a new case study to our website on Oracle R12 Upgrades – you can read this here.  We hope you find it interesting.

Oracle On Demand: Increasing Efficiency – Part 3

(By Tam Kyle, The third part of our close look at Oracle On Demand and how to make it work for your business)

Oracle

So far, we have discussed how On Demand is provided, how the services are supported and how it’s licensed.  We considered the impacts of additional resources and modifications on your license entitlement and in the process, uncovered some potential ‘gotcha’s’!

When you purchased your licenses – and here I mean the Oracle E-Business Licenses (this isn’t specific to On Demand incidentally – it’s relevant to most Oracle E-Business Suite purchases), you will have done so under an overarching Oracle License and Services Agreement – the so called OLSA.

In this document (or sometimes attached separately) there will be a set of license terms and definitions. Buried somewhere deep in these, will be a statement noting that you are responsible for ensuring that a set of restrictions are not violated.

What is the OLSA?

One of these innocuous looking clauses states that you promise to abide by the Application Licensing prerequisites as specified in the Applications Licensing Table. So what? Well, the application Licensing table is a separate document (unfortunately usually provided via hyperlink!) intrinsically connected to your contract.

Importantly, it states your liability in the event of alteration to the middleware or technology components of the Oracle E-Business modules. If, for instance you have added tables to your instance then you’ll probably need to license the database AND the middleware application server.

Now, don’t think because you’re running your service at On Demand that this protects you from this liability – ‘Oracle made the changes’, you shout.  Yes, maybe so, but they made them on your behalf.  Someone at your company wanted them to be made, and somebody somewhere signed a contract that said you’d be happy to bear the consequences of such an action.

And here’s the rub – if you’re using On Demand at Oracle’s data centres, then they know exactly what’s been altered and how much it’s going to cost you.  After all, they provide the infrastructure!

You get what you pay for?

So, you’ve paid for the Oracle E-Business Suite licenses, you’ve paid for the Oracle On Demand Licenses, you’ve paid for the Oracle On Demand resources (storage, environments, VPNs and so on), and you might now be paying for Oracle database and Oracle middleware licenses, based on a technology footprint that’s owned by Oracle!

Furthermore, are you (or the DBAs at OOD) utilising Enterprise management packs to monitor the instances? Do you know if your contract allows these to be used without additional cost considerations?

Don’t get me wrong, even though that sounds like a hefty payment to one vendor, it may well be attractive compared to in-house provision, particularly in the case of an SME who just doesn’t have the resources available to provide high end Financial or HCM functionality on their own. Just be aware of what you’re potentially getting into.  Oracle holds practically all the cards here. You can’t hide the Oracle infrastructure footprint (and you shouldn’t) – because it isn’t yours.

What to do

So what do you do about it? Sometimes, in a situation when a business case is being written, the implications of a future modification might not be obvious, especially when those implications might be buried deep in contractual documentation hidden in a filing cabinet in a procurement department somewhere.

And don’t blame the Oracle guys providing your day to day operational support – they’ll probably be DBAs, server and storage technicians just trying to do their job and the likelihood is that they’ll be several layers removed from the costing implications of OOD.

No, what you need is to be armed up front – be aware of the FULL cost implications of making a decision to go On Demand. Speak to your potential On Demand Service Manager, and your Oracle Account Manager, and make sure that they know that you want to be fully briefed on any and all cost impacts – in advance of them  happening.

At the moment, many clients are going through migrations to Oracle E-Business Suite R12 – this seems to have triggered a hive of license impact activity.

Be aware

So, be aware – have the conversations, make sure you’re well prepared. Alternatively, speak to us. We’ll help you navigate the license minefield, or at least understand the impact.

Next time, we’ll delve a bit deeper into the implications of those Oracle E-Business modifications – whether you’re hosted at OOD or not.

%d bloggers like this: