TRIRIGA

Maximo Real Estate and Facilities (The Evolution of TRIRIGA)

Come for answers, stay for best practices. All we're missing is you.


#Maximo
 View Only
Back to discussions
Expand all | Collapse all

URL Field Defect and Work Around

  • 1.  URL Field Defect and Work Around

    Posted 03/06/26 04:42 PM

    Everyone knows that TRIRIGA (MREF) reporting is limited and is really only intended for simple reporting. For deeper reporting you need to turn to another tool like Power BI, Tableau, Cognos, etc. Well I have a customer that uses capital projects who has done exactly that using Power BI.  They have various dashboards and in depth reports for their users. One of the things they wanted to do was be able to have links to these other systems that contain and display information to the users from other systems without having to recreate all of the data in TRIRIGA. 

    To enable this I created a crosswalk record that has a url field that gets built. They select the type of crosswalk record, for instance Oracle Service Order and then put in the id and it will automatically format the url so the customer can just click the link and it takes them to oracle where they have all the financial information they need. This is really working out well and we are now up to about 6 different crosswalk types so that they can just click a link pop open a window and get the information they need fight from within TRIRIGA.

    If you hover over a URL field you'll see the javascript command that opens it. It'll look something like javascript:openUrlWithProtocol('https://urladdress'). The URL format for one of the types was going to be https://customer.url.address/?filter=project so eq '123456'. This seemed simple and straight forward. Building the base URL was simple, the only difference is instead of spaces and single quotes they were replaced with their equivalent %20 and %27. When I went to test the functionality, the URL field was being built correctly and everything looked correct. However, the URL field was no longer clickable to open up the window. I could copy the url out of the field and paste it in to a browser and it would work.

    I noticed  the javascript command looked different though. If I hovered over the link or copied the link value instead  of looking like javascript:openUrlWithProtocol('https://customer.url.adddress/?filter=project%20so%20eq%20%27123456%27') it instead looked like ('https://customer.url.adddress/?filter=project%20so%20eq%20%27123456%27%27). Notice the final quote to close the url string in the java command was converted to %27 instead of being a ' like at the beginning before https. I tried changing the base url from using the %20 and %27 notation to the actual characters and it still resolved the same way and did not work. I believe we have a platform defect here in the 5.0 platform where it doesn't handle the URL correctly if it ends with a single quote. I suspect because its ending up with two single quotes in a row, which is sometimes a method of escaping a special character to indicate the character and not the special treatment of that character.

    I began searching and seeing what I could do to get the URL field to work as this is a major quality of life thing for customer. I did some research to see can I escape these characters in a different way that might work, like hexadecimal or maybe even octal format. So I asked AI how I could escape it.  Funny thing is it wasn't what it said I could try that interested me but what it said would not work:

    What does not work as a general substitute

    These forms are not defined by the URL standard and will not be interpreted as ' in general:

    • \x27 (C/JS style hex escape)

    • \047 or \27 (octal escapes)

    • HTML entities like ' or ' in the raw URL bar

    See that \x27 is an escape for JS? Well the command getting created is JS.

    I replaced the %27 values in my base url with \x27 and then tested the url.  The URL was building correctly, copying the link or hovering over it showed only one %27 at the end. And more importantly, the URL field was clickable once again. I was able to click the link and have the appropriate oracle financial information load for that service order.

    I'll recommend the customer put in a PMR for this defect. I don't know if they will take the time to or not since I was able to successfully work around it. If not, here is your notice IBM. This is in a TRIRIGA 11.6/5.0 environment where this is happening.

    Anyways, I just wanted to put it out there in case anyone else is having trouble with URL fields.



    ------------------------------
    Mark Johnson
    Senior Architect
    Wipro
    Bentonville AR
    7025088528
    ------------------------------


Related Content