BIP: Number to Text , complex version

Oracle never ceases to amaze me. I recently saw this question being asked again on stackoverflow.

Basically, this is an RTF template supposed to print a check. And the amount has to be converted to text, to be printed on the 'Amount' line on the check. BIP provides a function for this called xdofx:to_check_number.
It is documented over here. The function can print the output text in different locales, and decimal number settings. But the number to be printed has to be in an XML node. It only accepts simple XPATH notations, and the value itself cannot be a result of a sum() function, or the result of any mathematical operation.
Which means, if you have an XML like this:

<root>
     <amt>3243243</amt>
     <amt>6436464</amt>
     <amt>243</amt>
     <amt>445454</amt>
     <amt>67676</amt>
</root>

And you want to print the output as the sum of all the 'amt' elements, that cannot be done.

<?xdofx:to_check_number(sum(amt),'EUR')?>

Outputs:

Zero and xx/100



Which leads me to say: WTF Oracle ?

I had solved this problem years ago, but I couldn't remeber how. So I deep dived, again, into the same problem.


Using the RTF template, I exported the XSL-FO stylesheet out:

This extracts the intermediate XSL file BIP uses to generate the final report output.
Search for "to_check_number" in this XSL:

It can be seen that although there is a for-each loop there, the template itself is not called recursively.  It access the element 'amt' without a proper XPATH, and then does a stupid (.///)[1]  whatever that means.

But if you pass a string with the number into the function to_check_number, this works out perfectly.


For the foe-each loop to sum up all the values, it has to call itself recursively. Obviously, this function is broken.

But is there a way to fix this ?

Turns out, there is. Look two lines lower in the XSL file.



It can be seen that the XSL finally invokes another hidden function xdoxslt:toCheckNumber. This namespace is unique, I am guessing it is shared between the XSL and XDO name spaces.

So I tried using this 'hidden' function directly in the template.

Like this:

<?xdoxslt:toCheckNumber($_XDOLOCALE, sum(amt), ('EUR'))?>

Which produces the output:

Voila !!

So in case you have to convert a dynamically generated number to text, use the toCheckNumber function directly.

Which leads to the question, why have the xdo function in the first place ?

But do bear in mind, that this is an undocumented function, which works for now.

Hard sell

 

Been hearing some stories about Oracle's power plays here in Australia. It seems they are strong arming existing customers to force them to move directly into their cloud offerings.

And it is not even cheap. Instead of a direct upgrade of any on-premise siebel installation, they are trying to sell my current client their CX cloud offering. With a total cost of 10 million over 5 years ! 4 million per annum for CX cloud !

This is a hard sell. Specially looking at other alternatives in the market.

So it was no surprise there, when we unanimously threw that option out of the window.

So now, back to  Siebel On-Premise for now.

 

OpenUI , I get it now

 

After years of questioning it , I am starting to understand the reason why people are crazy about OpenUI.  For decades, the crude activex based frontend was a big pain area in Siebel. Customers were always using an older, outdated version of Internet Explorer for Siebel CRM, because the latest version never supported it. There was also that crazy 32bit, 64bit IE version problem.

So when the move to a open standards based frontend was announced, it was welcomed with open arms. No more IE. Any browser, any device. But  then started the crazy ideas, crazy configurations, outrageous themes. People started implementing all their business processes purely in OpenUI ! I have stayed away fro this kind of work, for a long time.

But for the past 6 months, I have been working on pure OpenUI requirements. For integration. Yes, Siebel EAI integrations triggered from OpenUI ! Only reason I agreed to it, was because that was exactly what my customer wanted. And the challenge was too sweet to ignore. Javascript is a horrible language, but with OpenUI, it opens up possibilites endless.  Whatever restriciton Siebel puts up to you, can be bypassed in Javascript. I was able to implement a purely asynchronous VBC like applet in OpenUI, something which is not possible using traditional Siebel code.

But OpenUI works poses its own challenges. Unlike tools, there is no object locking system, so better have some kind of CVS in place  if you have multiple people working on OpeUI files. Also, test in every browser. Do not assume that IE or Edge will honour the code the same way Firefox does. Test your code specially with the  Show More button on the applet (tip),  because Show More has lots of issues in OpenUI.

And finally, Siebel still provides the best architecture for a CRM system. Try to implement whatever you can OOB, and OpenUI should be the last option. Unless you want to get into maintenance hell.

 

Too Much Javascript

 

I can't understand this trend. After years of focus and interest in compiled languages and binary executables, now everyone is focussed  on what can be done in the humble browser. And its programming language, Javascript. And that's where the action is. Everyday I hear about new javascript based libraries and frameworks. And the language syntax is getting worse. With new conventions of invoking script and processing data, its almost as if they are re-inventing multiple wheels again. There are new graphing and charting libraries, and it is now possible to build entire standalone desktop applications running on javascript. It seems to be everyone's favourite, enjoying a position once occupied by Java. I can straightly see the advantages of moving your UI code to Javascript.

• It is truly portable. Runs in all modern browsers, even on smartphones and tablets.
• Flash and Java, the previous leaders in browser programming, are no longer supported by newer browsers. Maybe due to security vulnerabitlies in them.
• None of that bytecode compilation you see in Java class files.
• The source stays with you, so it is still modifyable.
• It is free. Truly free. It is open source.

But I can't help noticing that it greatly increases the amount of data being downloaded into the final browser. And takes up a lot of bandwidth. Sure, many of those applications use require.js and files are loaded only conditionally. But still, they need to be downloaded. And the humongous task of executing the program is now transferred from the server to the end-user's browser. Which is definitely good for the server, lesser load balancing to take care of. But on many sites, I can actually feel the browser slowing down due to the additional processing power it needs.

I like browsing light weight. I sometimes turn off javascript completely on some news sites, I feel it gives a much faster rendering of the site, as none of those additional garbage is loaded and run. The URL links still work, because those are in the HTML.

But the bigger problem is see is un-regulated development. Everyone is writing their own libraries and packages. First it was just google and facebook. Now even new players like oracle has entered the race and are giving out their own libraries. And the tutorials of all their libraries does the same thing: render graphs and charts in the browser.

Too many tools. Too much configuration. That is the problem. Javascript experts have written better about these problems, so I will leave that there.

The bigger problem I see lines of code. After programming for more than 20 years now, I have learned to understand is that the real challenge (and fun) in programming is to achieve maximum tasks writing as little code as possible. You don't have to be Phd to understand that it is easier to debug and test a 10 line program than a 100 line program. Every extra line added to the codebase increases the difficulty in debugging it at a later stage. Not to mention the huge effort of merging code written by large teams during checkin. But all these javascript based boilerplates, linters and generators don't solve this problem, they just make it worse.

A library should be simple enough to add it into ones current code base, and the developer should not have to know how it is implemented to use it. All the real work must be transferred into the library being invoked, leaving the base code base minimal. Minimal. That should be the keyword.

Or there should be a way for RAD tools. A system of abstractions which will hide the complexity beneath and generate highly efficient code.

When I started work in Siebel, I used to hate the idea of Enterprise Application development. But I absolutely admired the way Siebel had built a layer of abstraction and user properties, and through them, indirectly invoked C++ code to achieve its functionality. Sure there is one extra layer in this packaged application method, but the final code which the consultant/developer writes is very minimal. I have seen entire projects implemented with a total of less than 1000 lines of escript code in it.

I was looking into the new Oracle JET library for javascript application development which was created by Oracle and it is completely bonkers. All they have done is to re-implement a couple of already perfecte ideas and re-do it in their own way. A lot of the final code looks exactly the same as from Angular or React. I have no idea why any enterprise customer would decided to writes thousands of lines of javascript code just to get charts rendered in the browser, when other Oracle delivered  packaged and cloud applications can do the same without ANY lines of code.

Hope somebody sits up and takes notice.

Siebel and Stackoverflow woes

 

Ok, we are nearing the end of another year, and there's one more month till Christmas. I have now fully moved out of Siebel, and embraced the new family of Oracle Fusion cloud applications. But I do keep track of what happens in the Siebel world. If things finally start to fix themselves (that would be a big miracle), Siebel might make a come back. I am a member of various forums where they track Siebel queries, and one of them is stackoverflow. In some of my previous organizations, I could not even access this site, due to firewall restrictions, but time and again the resources on the site have helped my own project problems. Though I have not yet asked any question on the site, just answered other's queries, and read what other's have left there. I have not asked direct questions because I want to solve my problems in my own capacity, Maybe its my ego, but I won't put up my requirement on the page and wait for some one else to solve it for me at no cost at all.

But that hasn't stopped others. And following the questions on the site gives you a good idea of what issues other Siebel developers are struggling with. At the moment of writing, these are the stats on the Siebel tag at stackoverflow.

Two years ago, there was a lot of activity around this tag, people were actively asking for and receiving help, the range of topics was wide. Here is a screenshot of the site from the waybackmachine from the start of this year.

Yep, back then, all questions were answered and there was more activity. But now the tag attracts weird questions mainly from css and jquery , because Siebel now uses OpenUI. There appears to be a bunch of noobs with only some basic Siebel training, who visit the site to mainly put up their own requirements, then wait patiently for someone else to solve it for them.

Like this guy:

Or this classical one which is a link issue, and  which is even documented supportweb.

Clearly, the Siebel pool of resources is decreasing in size. And its the same trend everywhere. Well, Siebel was always closed technology, at times the only place you could get help was on the Siebel support centre, specially about 10 years ago.

Others too have noticed the decline of activity on IT Toolbox and have created a new Siebel page on Slack.  Good old Neel of SiebelUnleashed fame too has abandoned ship. In a very candid and frank interview, he clearly speaks out the writing which has been on the wall for years.

 

"Siebel jobs are going to be there for a long time but unfortunately I don't see many new implementation of Siebel."

"People are sticking to Siebel either because they are heavily invested or they believe other products don't offer what they need."

 

So I am still (and thousands more) waiting for that miracle to bring Siebel consultants back in demand.

Anyway, back to Stackoverflow. I was pondering on these questions when I ran into a fantastic article about how stackoverflow may be the best and worst part of programming today. According to their stats, only 27% of question remain unanswered.

 

Siebel IP 2016 - No More High Interactivity

 

This is from Siebel Innovation Pack 2016: Client Platform Support - Statement of Direction (Doc ID 2017902.1)

 

 

Also it adds:

 

The Failure Of Agile

 

I have always felt that Agile has failed. No Indian IT company I know of implements agile in its truest form. So it was not surprising to see one of the creators of agile himself ranting about this. He is also proposing a new standard.

Enjoy.

IP 2014 - Aurora theme

 

 

This is my reaction on seeing the new Aurora theme in Siebel IP 2014.

Worst software I have used

This is something I have been planning for months, maybe a year now. As part of my work as a Software consultant, I have had to use some really terribly designed and poor performing software. Here is the top 3 , (or worst 3) so far:

 

1. IBM Lotus Notes (I used version 8.5):  In a world where simplicity ,ease of use, and minimalism is gaining appeal, Lotus notes dares to go miserably against the tide. It is slow, hogs memory and resources, and follows and out-dated layout style. It would be easier for a newbie to master a flavor of  Linux system than to get used to Lotus notes. Also, it does not merge into Window’s theme system, further showing its age. It even lacks functionalities you have come to expect from an e-mail system; like forwarding meeting requests, and recalling sent mails.
2. BMC Remedy:  I was on a support project for over a year, and the part of my job I hated worst was where I had to use and update the ticket details on the Remedy system. Its ironic that they thought of such a name when it does not remedy anything ! Again, the aged look and feel and cumbersome navigation itself put me off. But it was also terribly slow; so slow that on many occasions I missed SLAs because the system did not respond on time. And if you are planning to run long queries to prepare your reports on this dinosaur, be prepared to lose hours with the hourglass spinning. I used to start a query and go get a cup of coffee before the results came out. We used to joke that we need to bill 1 hour to Remedy ticket updation separately over and above our usual bill hours, because our productivity during that time was absolutely zero !
3. HP Quality Center:  I used to like using the earlier version of this software, when it was still called Mercury Quality Center. But after the last upgrade, when it moved to the latest HP QC version, I found I was spending more time updating QC records. The fact that it uses ActiveX and runs  only on IE was further complicated because it hogged up memory, and frequently crashed.

 

There ! I said it. That takes some weight off my chest :-)