BEA Weblogic and my CCA install - this one caught me out

IT & Telecoms are full of rat holes as an old colleague of mine described them. Some, as Mick described them, are Mink lined - they're the best and hours can be wasted foraging around in them. My latest rat hole wasn't that much fun, but none the less provided an hour of fascinating diversion from the job in hand.

The actual task was to look at setting up and validating scheduled reports in Oracle CCA Fix Pack 8 (you can appreciate already why a rat hole would be very attractive at this point). Task in hand I opened up a browser and logged into my VM CCA environment, navigated to the advanced reports section of my test tenant (Aeonvista of course) and clicked on user login/logout - nice easy one - went through set-up and all looked got - including the schedule tab and email details entry... .So far so good.

OK to the test client (Supervisor Java App) login, select reporting and click on the login/logout report .... and crash - well error .... Hmmm.

Back to the Admin screen, click view report, Java Error in the page:

java.lang.NoSuchMethodError:org.apache.commons.codec.binary.Base64.encodeBase64String

Now this was a surprise - my test environment is pretty clean - and I was sure this was working before... Then I remembered I'd done an upgrade from FP5, Hmmm .... surely there wasn't an old library included in the new release - that would have been rubbish.

Warning --- Rat Hole --- Warning --- Rat Hole --- Warning --- Rat Hole --- Warning

So now I had a problem to investigate, which was much more fun than the original task. A quick search turned up a stackoverflow post, with someone with a similar issue. So to find the offending library.

A quick look in the WEB-INF/lib folder showed commons-codec-1.6.jar - OK looked like the latest version - should contain the Base64 encode method required. To the AdministrationManager/report code folder, the JSP page is cr_choose_period.jsp and the offending lines:

<%@ page import = "org.apache.commons.codec.binary.Base64" %>

.........

String credentials = Base64.encodeBase64String(sbCredentials.toString().getBytes());

The second line was were the error was appearing and the first showed me the library was being included - so - what's going wrong? To work on a bit of JSP hacking - now its been almost 10 years since I even touched any JSP - some serious cobwebs to clear out of my brain cells for this one... Quick hack at a debug version of the offending JSP file and I had cr_choose_period.debug.jsp, with:

<%@ page import = "org.apache.commons.codec.binary.Base64" %>

<%@ page import = "java.util.*" %>

.......  
  <% out.println("Hello World"); %>
  <%out.println(request.getRealPath("/")); %>
  <%out.println(Base64.class.getProtectionDomain().getCodeSource().getLocation()); %> 

The pop-up dialogue (window) now showed me it was pulling a defunct (outdated) 1.3 library from: 

C:\bea\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_user

So stop the BEA Weblogic service, delete the contents of the tmp directory, restart weblogic. Check the debug page - excellent now pulling the correct library from the WEB-INF/lib directory. 

C:\bea\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_user\TAW\qaiheg\war\WEB-INF\lib

Re-instate the correct cr__choose_period.jsp code and - HEY PRESTO - the dialogue (window) now has the date time chooser in there.

Rat Hole End

Now I was back on track setting up the scheduled reports.

Happy Birthday 999 - 75 years today

For those outside of the UK 999 is the UK Emergencies services number for Fire, Police, Ambulance and Coast Guard. Other Countries have selections of numbers with the most widely recognised in Europe 112 and in the USA 911. There is a nice little potted history on Wikipedia and an article in yesterday's Metro Newspaper, a capture of the printed article below.

Metro Newspaper article Friday 29th June 2012, Copyright Associated Newspaper Ltd

I have had the privilege to work on the technical implementation of the Operator Services and Emergency Services feature on the UK network, on three occasions:

• The first in the  mid-1980s in the Plessey Poole factory on the System X Operator Services Subsystem (OSS), with a talented team developing the technology for the core exchange and the Operator console and voice distribution elements.
• The second occasion in the early 1990s with Mercury Communications Operator Services, implementing the OSS in the carrier network to handle all the operator services, from Directory Enquiries, Operator Assistance, and of course Emergency Services. This gave me a real insight and respect for those taking the calls from the public, their cool, calm and professionalism of the operators and emergencies services bureaux staff in handling customers at their most vulnerable. It also taught me respect for the service itself and I have to say a sprinkling of contempt for those members of the public who would misuse it making unnecessary calls for trivial and quite frankly stupid things such as asking for a taxi!
• The third occasion I have been fortunate to be part of the very important standardisation process for the migration of the emergencies services handling to the VoIP world, with the UK independent standards body, the NICC Emergency Services Location group, and helped to produce the UK standard for this. This taught me another valuable lesson in the dedication and free contribution a number of very committed and talented people from around the world make to ensure the safety of the public.

HAPPY BIRTHDAY - 999!

Investigating Asterisk 1.8 and Apstel DialPlan Pro

This last week apart from the usual "day job" at News Int, I've been looking at Asterisk 1.8 and Apstel's DialPlan Pro. I took a look at this a little while back before it was quite as mature as it is now. I'm very impressed with the ease of creating dial plan logic and its ability to recognise the different flavours of Asterisk addons you may be running - such as Trixbox, AsteriskNOW or PIAF for example (FreePBX).

I opted for a Native install of Asterisk 1.8 on 64 bit Centos 6.2:

Asterisk 1.8.8.2 built by root @ apstelasterisk on a x86_64 running Linux on 2012-01-28 23:19:09 UTC

I've favoured Centos for my server builds for some time now and built a successful Asterisk and SER hosted telephony platform back in 2004/5 based on Asterisk 1.2 code using Centos 4 back then. I've swung to Ubuntu for my desktop builds and like many don't find the latest Unity interface to my liking so these days my desktop is Mint or XUbuntu, and of course my now constant OSX Lion desktop on my Mac Mini.

Back to the current project, I've got a customer who wants to built a telephony platform for a large-ish volume of callers who will be required to complete automated surveys (IVR) and both the survey results and in a number of the calls recorded feedback from the caller. There will be a fair number of prompts to record and playback too, with the Initial system starting with a single PRI (E1) worth of calls, and the platform requirement scaling to up to 8E1 of traffic. The customer needs to be a self sufficient as possible, building their own dialplans and IVR logic Apstel's Dialplan Profession and Integration Server is perfect for this.

Whilst Apstel's GUI hides the complexity and errors that can creep in to an Asterisk dial plan built using text editor, it can also lull the user in to a false sense of perspective of what is actually happing within Asterisk. This means that whilst Apstel's Visual Dial Plan Pro (VDP) application is a great tool, it is not a substitute for knowing how the Asterisk dial plan works. If fact you can end up with some very ugly and inefficient dial plans if you're not careful.

Using Apstel VDP, you still need to plan your dial plan and carefully understand your requirements and what you want to achieve before building the dial plan logic. Next time I'll take a look at VDP and go through the settings and some screen shots of how this application interfaces with Asterisk.