Home page Home page Home page Home page
Pixel
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
Pixel
By Sprezz | Tuesday 28 December 2010 16:50 | 2 Comments
Just before Christmas we were invited by one of our clients to visit their site and to perform a number of OI related tasks in a very finite time frame. Specifically to upgrade a 16 bit OI 3.7.5 production system and an OI 8.0 web based system to OI 9.2+ whilst installing the UD Heavy. We were allocated 5 days to do this so were confident that it was achievable.

Of course our confidence was rooted in real world experience - both of of our combined skill sets and of typical UK weather...

So early Friday afternoon came and exercising caution the Sprezz lead consultant ("the Sprezzie") on this project began the 200 mile drive to the client - this was to be a Sat/Sun/Mon/Tue/Wed job to minimise impact on the factory production system and to fit in with some tight scheduling requirements for Sprezz. Unbeknownst to us this was to mark the beginning of some of the worst weather in recent UK history. In a normal world this 200 mile journey would take 3.5 hours.

Two hours into the journey the Sat Nav decided to change the route due to traffic conditions ahead and rerouted the car to within 20 miles of the original starting point then started again... snow was blizzarding and road conditions were becoming treacherous. Average speeds dropped and past experience of snow driving became essential. The next 5 hours or so were not fun but eventually the Sprezzie arrived at their target hostelry - a snowed in Bed and Breakfast in the middle of nowhere - just in time to discover that after a 7.5 hour journey, all the places serving food had shut. And so to bed.

The next morning dawned and the 12 mile drive to the client had never looked so difficult. The roads were snowed in and the gritting lorries had yet to visit. Thanking providence for front wheel drive the Sprezzie eventually got to the client and started work. The initial UD Heavy installation was a cinch, it installed and it did what it said on the tin. The 4.6 UDH is one we at Sprezz Towers have a lot of experience with and we have no hesitation in recommending it to our clients. It addresses a lot of issues found in previous releases of the UDH and the documentation is an order of magnitude better!

The 9.2 upgrade was a bit more of an issue - the install was fine but combining the 3.7.5 and the 8.0 system proved to be a bit more of a challenge. Eventually two APPBACKUPs were taken and a custom program was created in conjunction with the client to combine "the best of both worlds" and this custom program installed all elements into a virgin 9.2 system without the need for an APPRESTORE.

Everything came together BUT the system wasn't running for some reason. So thus began the multi-sourcing quest. First off we downloaded Sprezz's "Recompile All" utility. This recompiled all events, stored procedures and windows. Things started to run again but the windows looked ugly. So then we downloaded Rev's "Font changer" utility and changed all the fonts to Tahoma in Windows and Popups. Finally we downloaded and ran SRP's form fixer to reset the errant style bits and we were back in the running.

Next up the client agreed that hiding the LK and OV files was a worthy goal - no more users accidentally trashing systems. So we followed the incredibly simple instructions in the UDH installation guide and attempted to hide the files. It should be said that the installation was on a 64 bit server. The Sprezzie in charge tried and tried but could not get the files to hide - the registry settings would not take. So throwing it open to all Sprezz crew he mailed the internal distribution list and was cajoled by colleagues into triple checking his registry entries. To much embarrassment it became apparent that Rev create two key sets in the WOW3264 section - one as Revelation Software for the client - and one as RevSoft for the UDH. It behoves the developer to use the RevSoft key if s/he wants Shares to work...

So onto the next thing on Santa's wish list - converting their OECGI installation to OECGI3 on an IIS 7 web server. Quick start read, product up and running in less than an hour. Way to go RevSoft! These quick start guides REALLY help.

Starting to wrap up and wind down the client mentions that they'd like to convert their existing mail server (all based around Rev's MAPI technology) to a more future proof technology. No problem - Sprezz's free SMTP mail client is downloaded and installed and the conversion of the mail server continues apace - until.... what? You want to CONSUME mail as well as PRODUCE it? Uh Oh....

It suddenly became apparent that there is a gap in the RevSoft offerings...

GETMAIL as shipped with OI is a handy socket based POP3 mail client which pulls down the mail from the pop server and delivers it as text files to the client - the only downside is that it

a) is underdocumented and
b) it delivers effectively binary streams unlike the MAPI equivalent that delivers nicely documented structures.

Fortunately for us (and the client) the client only needed to consume several very specific mail formats so again mining the collective Sprezz gestalt we were reminded of the existence of BASE64DECODE in OI and were able to put together an OI based program to decode multi part MIME emails in a manner consistent with the existing MAPI calls. This allowed the existing Mail Server technology to be migrated to SMTP/POP3 with minimal change.

All in all a fun filled and technically challenging week made possible by the flexiblity of the OI product, the contributions of the Rev community and the whole being greater than the parts that is the Sprezz consultancy team.

Labels: , , , ,

2 Comments:

Post a Comment

Subscribe to Post Comments [Atom]



<< Home

Pixel
Pixel Footer R1 C1 Pixel
Pixel
Pixel
Pixel