doboski 310000SJR4 Visits (6204)
Have you have ever had performance issues with loading data into your location hierarchies? Or making large changes to hierarchical data? Are you reorganizing your company, adding new departments, moving or combining others? Is it taking a long time to process these changes?
When an update is made to the hierarchy, the entire tree is rebuilt. So if you have multiple updates you are making, it is rebuilding the entire tree. If you have a rather large tree with many layers or branches, this could be quite time consuming and frustrating while you wait for it to update. Do not fear! There are some things that can be done to make it less time consuming!
One of the things to look at is in your Admin Console. You would go to Cache Manager and look for System Cache Processing Mode. By default this is set to Normal.
You would want to set this to Data Load Mode and then click on Change Cache Processing. It is worth noting that when using Data Load Mode, it will not update the tree but it will be faster to process because it is not updating the tree after every single update. Once the process is done, the tree can be rebuilt once and not after every update.
You don’t have to necessarily go into the Console to set that every time you are adding something into a hierarchy or making an update. If you have a workflow that is currently used to process your hierarchy inserts and/or updates, you can add a custom task to turn on Data Load Mode and then turn it back to Normal after your processing is complete.
To set it to Data Load Mode, in the custom task, you would set the class name to com.
To set it back to normal, in the custom task, you would set the class name to com.
For additional information regarding custom tasks, you can reference the following wiki:
Many times, a client may hear a support engineer say that they should upgrade to the latest version. Why do I keep hearing that - especially if upgrading will take time, money, and resources? TRIRIGA, like all other software, evolves. We continuously fix defects and add new functionality. For instance, if you are on version 3.3.2, some of the features you cannot take advantage of include improved logging capabilities, which makes it easier for us to help you troubleshoot an issue. Also included is improved security and, more recently workflow versioning. Since complex software can sometimes have defects you never know when a defect might impact your business. But why wait for it to impact you? Upgrade so that it won’t happen. New functionality is also added into the software and you may want to take advantage of it.
Another reason to upgrade is that software uses various technologies, which changes faster than New England weather! Technology is constantly changing and TRIRIGA must keep up in order to keep it running. That technology can be in operating system updates, browser versions, application servers and Java to name a few. Support may often recommend staying current with product releases but it is always good to review the release notes for the current release. The release notes for each version show what has been fixed and functionality that has been added. You can find the release notes for TRIRIGA here:
Before upgrading, it is important to understand the structure of TRIRIGA because there are 2 very different procedures to upgrade. Those 2 structures are Platform and Application. The TRIRIGA Platform is the java code that IBM writes and is installed on a server. The TRIRIGA Applications are developed using the TRIRIGA Platform. Applications are not “written” but are developed using the Platform as a development tool. Applications are stored in the database as metadata and are not found in the TRIRIGA directory structure. Both the Platform and the Application have their own version number. How do I tell what number is for what? Platform versions are the lower of the 2 numbers associated with a TRIRIGA install. So the Platform version would be something like 3.5.1 or 3.4.2. Applications are the larger numbers associated with a TRIRIGA install. So the Application version would be something like 10.5.1 or 10.4.2. TRIRIGA 3.5.1/10.5.1 is Platform 3.5.1 and Application 10.5.1. But this can change. If IBM releases a 4.1.0/11.1.0 release, a client can upgrade to Platform 4.1.0 and leave the application at 10.5.1. But you can never upgrade the Application beyond the platform it was built on. So using the example of 4.1.0/11.1.0, you could not upgrade the application to 11.1.0 and still be on platform 3.5.1 because the functionality required to support the new Application exists in the new Platform.
The TRIRIGA Platform will always be there as it is required for the database to be run. The Platform never deprecates functionality. So if an application is developed on one release of the Platform, it will continue to function in future releases of the Platform. Ever since the 3.2 release, you can easily upgrade the Platform in under 2 hours. You simply stop the servers, install the new platform code, start one server to perform the database updates and when it is complete, stop the server, apply the latest fixpack, start one server and then start the rest. That’s it! The Platform will be upgraded. Security vulnerabilities, new technology, performance enhancements, new properties and more are ready to use. You should plan to perform a Platform upgrade at least once a year.
Applications can be substantially more complex. If you have never done one, I would strongly recommend that you consider engaging our IBM Global Business Service (GBS) or one of the IBM TRIRIGA certified business partners to help you through an application upgrade. Since the applications are actually data in the database, an upgrade involves updating data, which is always a tricky task. On top of that, clients have the ability to configure and modify functionality associated with an application. A wrong step could overwrite data and damage functionality. To add to it, application upgrades must be done one version at a time. If you on 10.3.1 and are going to 10.5.1, then you will need to upgrade to 10.3.2. Then 10.4.0, 10.4.1, 10.4.2, 10.5.0 and finally 10.5.1. We strongly recommend that you plan for an Application upgrade at least once every two years to minimize the number of versions between platform and application. In addition, audited functionality may require Application upgrades. Customers who use the Lease functionality in TRIRIGA will know that government rules around leases are called FASB. Clients who need to be compliant with FASB rules will need to be on the latest Application release.
Fixpacks are important too! If a defect is found in a release, we will identify the defect as an APAR and develop a fix that can be applied to the installed software. It is recommended that customers set aside time and resources once a quarter to apply any fixpacks.
When a support engineer recommends that the user should upgrade to the latest version, the first thing that should be done is plan! Just because the platform may not take a lot of time to do, you should put in the proper planning. Here are somethings to ask yourself when planning your upgrade:
JeffLong 270005B0Q4 Visits (9094)
With the changes delivered in IBM Tririga Platform 3.5.1 there is now a better way to track changes to objects in Tririga and a new naming convention that has been introduced for Object Labels and Revisions.
Here is a great link providing information on this change for Tririga Platform and additional links to related resources:
doboski 310000SJR4 Visits (9538)
One very powerful aspect of TRIRIGA is the ability to configure it for your business needs. Of course the biggest drawbacks to TRIRIGA is the fact that it is configurable! OK, that’s a bit of an inside joke here in the IBM TRIRIGA Support team. We love that people can make TRIRIGA do what they need it to do, but if they don’t follow best practices, everyone suffers. The end users suffer slowness, the administrators try to figure out what has gone wrong, the IT team struggles with hardware and architecture configuration and the IBM Support team has to figure out what the implementer did that may be causing the problem – even though it’s probably outside the scope of support. Queries can be one of those things that can be impacting your performance.
So I want to specifically talk about custom queries and what you can do. Depending on how you create your queries, custom queries can have an impact on the performance of your system. In your custom query, when you create an Association Filter, you want to avoid using –Any for the module selection and All for the business object selection. The reason to avoid those particular selections for your Association Filter – is it can cause potential report performance issues This is mentioned in the document 3.4.2 Reporting User Guide found here: http
You are better off specifying a specific association type in your Association Filter than to use –Any.
If you have any fields that have a special character in them, like < >, &, * or - that can also impact your performance. While field names should not have < >, &* or – in them it could happen somehow. If any of your fields managed to have special characters put into them, then this is going to cause issue with your reports, because the Reports will not be able to be built. So it is a good idea to NOT use any special characters when creating your field names. If you have special characters in any of your field names, it will be best not to have it referenced in a query. Ideally, you will want to create field names that do not use a special character.
It is important note to remember that if you have modified your custom queries, that you need to clear the Query cache from the TRIRIGA Admin Console for the change to take effect.
You will find this performance tip and many more in section 7.2.2 of the TRIRIGA Performance Best Practices guide at the link below. Support will often refer clients who report poor performance to this guide before engaging in any troubleshooting.
IBM TRIRIGA - Secure Sockets Layer (SSL) between the Tririga Application & Database is not supported
JeffLong 270005B0Q4 Visits (8375)
We were recently asked for guidance on setting up SSL (Secure Sockets Layer) between the Tririga Application and the Tririga Database. Although this may be technically possible, setting up SSL between the Tririga Application and the Tririga Database is not recommended and it is not supported by IBM TRIRIGA Support.
If you have a need for enhanced security for your IBM Tririga solution, please contact IBM TRIRIGA Support for assistance. We will work with you to offer supported solutions that meet your needs.
IBM TRIRIGA - When viewing associations on associations tab, the lines connecting objects are not solid.
The cause of this is that the rendering of Native SVG graphics is handled on the client side in the client's web browser, and different browsers render the Native Scalable Vector Graphics files in different ways. This can result in the same SVG file looking different depending on the browser chosen.
If you are reviewing Tririga associations and you are having trouble viewing them, try to find a different web browser that renders Native SVG in a way that better meets your requirements. If this is not an option, you can also contact support for the browser vendor for additional assistance.
IBM TRIRIGA - What are the differences between Fixpacks and Limited Availability Fixes and what are best practices for fixes?
JeffLong 270005B0Q4 Visits (8963)
Occasionally we have IBM TRIRIGA customers who need clarification on the differences between Fixpacks and Limited Availability fixes. I want to share this information with you and state best practice guidelines here:
GENERAL AVAILABILITY FIXPACK (GA FIX)
GA Fixpacks deliver product defect fixes that have undergone a full development release cycle and the most extensive QA testing of all maintenance releases.
These fixes are delivered for any issue reported either internally or externally regardless of severity. Fixpacks occasionally deliver minor functional enhancements and modifications to add or update supported platforms, browsers, databases, middleware, etc.
Fixpacks are cumulative and each new fixpack contains all fixes from all previous fixpacks/interim fixes for that release.
LIMITED AVAILABILITY FIX (LA FIX)
An LA Fix is an unofficial mechanism to deliver emergency fixes for severe product issues that cannot be delayed until the next regular maintenance delivery. LA Fixes also go by the names “1-off” or “1-off Hotfix” but they all mean a single APAR fix delivered directly to a customer from Support.
Conditions that may warrant an LA Fix
Risks associated with LA Fixes
BEST PRACTICES FOR FIXES
It is perfectly acceptable to take an LA FIX to address an issue when warranted. However, the risk associated with taking an LA FIX should always be weighed against the perceived benefits. If at all possible, it is always best to wait for a fully tested GA Fix. Also, if you do take an LA Fix, it should only remain in place until a GA Fix containing the fix needed is available. At that point, the GA Fix should be applied.
JohnONeill 270004JPGF Visits (6268)
There is a potential issue with the shutdown process for TRIRIGA. This is specific to versions prior to TRIRIGA 3.5.1 running under Windows with Websphere Liberty Profile (WLP). We have found that the SHUTDOWN.BAT file may not end the session. If you encounter this issue you can resolve it by adding the path as described below.
In TRIRIGA 3.5.1 for both the RUN.BAT and SHUTDOWN.BAT we include a step to change directory to the location of the server.bat file as below.
(Note: In notepad there are no spaces or carriage returns between the rows.)
@echo offset JAVA
It looks like this in other viewers
echo JAVA_HOME : %JAVA_HOME%
echo CLASSPATH : %CLASSPATH%
cd /d /hom
server.bat start tririgaServer
cd /d /hom
server.bat stop tririgaServer
However, in previous versions that path is not included:
TRIRIGA 3.4.2 (shutdown.bat)
server.bat stop tririgaServer
TRIRIGA 3.5 (shutdown.bat)
server.bat stop tririgaServer
If you encounter an issue where the shutdown.bat file is not working you can resolve the issue by adding the path to the server.bat file similar to the example below.
cd /d /your_path_to tririga/wlp/bin
server.bat stop tririgaServer
There you are, planning an application and platform upgrade for your IBM TRIRIGA installation and you think everything is working just fine. You roll out to production and for the first few days afterwards, all is quiet. Suddenly, out of the blue, you notice that the floor plan graphics no long render. Where the graphics should appear, you do not see the No Graphic Available message where the graphic used to appear. What you do notice is that, in the lower right hand corner "Error 2" is displayed and the rest of the space where the graphic would normally appear is blank. This blog post will address one of the potential causes of this problem and also a means of finding the problem before you upgrade your production environment.
In order to determine the root cause, we need to know what the errors are that are referenced in that "Error 2" text in the graphics section. Clicking on the text will open a pop-up box that contains the actual error messages (2, hence the "Error 2") related to the issue. That alone will not help the support team diagnose the problem. The errors should indicate an MID number. That MID number should also be found in the server log with a time stamp associated with when the graphic should have been rendered. In a issue I was working for a client, we determined from that information that there was a problem with the graphic layer configuration records. In particular, they were missing their corresponding IBS_SPEC entries. This required removing the records from the database using SQL run against the database back end. The application is unable to delete the records because the application relies heavily on the IBS_SPEC table entries to perform the actions necessary to delete the records. Once the records were removed and the layer configuration records rebuilt, the graphics once again started to display.
Great, that fixed the immediate problem, but how do you prevent this from happening in the future? When planning your upgrade, you need to insure that all graphical functionality is tested before making the decision to roll the upgrade out to your production environment. Upgrade plans should always include CAD Integrator testing. In older releases of the IBM CAD Integrator tool and the IBM TRIRIGA Platform, there was a great deal of backward compatibility. As a result of this backward compatibility, most clients did not include steps to insure that graphical elements were unaffected and, instead, focused on the business process logic to insure that the non-graphical data was correct. With the later releases of IBM TRIRIGA (3.3 or later, to be more precise) the CAD Integrator tool became much more tightly coupled with the platform release. Best practice for upgrade planning should now include upgrading the CAD Integrator tool to the release that was created specifically for the platform release to which you are upgrading. As a result of adding the CAD Integrator to your upgrade plans, you should naturally expect to add more time to the validation of all CAD related graphics that appear in your IBM TRIRIGA instance.
If you found this blog post useful, be sure to 'like' the post. If you have any comments about this blog, please provide that feedback in the comments section.
JeffLong 270005B0Q4 Visits (6683)
We have had a few customers contact us because they could not start or stop Tririga on IBM WebSphere WAS Liberty Profile. We found that the way to resolve the issue was to implicitly run the batch file as Administrator on Windows OS.
If you have a need to restart Tririga on WAS Liberty Profile in Windows you must first find your tririga_root install path. If you used the default for the installer, this should be C:\IBM\Tririga. If you are not sure of the location, you can search for the following files (these should be in the Tririga \bin directory.): "run.bat" and "shutdown.bat"
To stop Tririga, navigate to the trir
Alternatively, on Windows servers, you can open a command prompt and run the command to shut down the Liberty profile: trir
To start Tririga back up, navigate to the trir
Alternatively, on Windows servers, you can open a command prompt and run the command to start the Liberty profile. trir
If you need further assistance please contact IBM Tririga support.
JohnONeill 270004JPGF Visits (8932)
You may encounter an issue where the MS Outlook Reserve Add-In is not functioning properly. What you see is that the Book Selected Room button flashes briefly nearly off the page such that you can only see the left edge, then the Book Selected Room button disappears. Also the Book Selected Room button at the bottom and most other controls never come in to focus. Other controls do not function and no reservations can be made.
Following is an image of the MS Outlook screen in question.
This may be caused by a configuration of Registry and IE Compatibility Mode setting.
Resolving the problem
It is necessary to ensure that the correct registry entry exists AND that Internet Explorer Compatibility Mode is not set.
Here is a link to the Microsoft web page that describes the FEAT
JeffLong 270005B0Q4 Visits (9955)
Planning for a new install or migration of an existing IBM Tririga install can be a complicated endeavor because there are so many different possible configurations for the IBM Tririga n-Tier architecture. Below are some links that will help you with your planning.
This is a lot of information to go through, but taking the time to review this information during your planning phase of your install or migration will allow you to make informed decisions based on your intended use of the IBM Tririga product and plan accordingly.
Chris K 270004Y3TR Visits (8996)
Having been on the customer side of the IBM Support dialog, I often wondered why I was always asked for version information for my PMRs. Now that I have been working on the IBM TRIRIGA Support team, I understand why. The purpose of this blog will hopefully shed some light on this for the customers as well as improve the customer experience with the IBM TRIRIGA support team.
What the IBM TRIRIGA support team will be doing in the weeks ahead to help make things a bit easier is ensuring we have up to date information about customer versions of the IBM TRIRIGA Application Platform, IBM TRIRIGA CAD Integrator (if applicable), and other third party components required for a running the TRIRIGA application. To that end, we will be asking for information from you if you open a PMR without including the version information for the IBM TRIRIGA issue (whether it is an application, platform, or CAD Integrator issue). Additionally, if you do not indicate what environment this issue applies to and the associated version information for that environment, we will ask for that information as well.
What you can do to help is to provide this information up front when you open a PMR. I suggest keeping a document with the environment configuration information. Having been on the client side of this picture, I know how I ended up making the IBM PMR process easier for me. Knowing that I would be asked version information right out of the gate, I kept a document which had the version information for the main product as well as versions of other products in our configuration that could have an impact, in any possible way, to the problem being reported. I found that this greatly smoothed out the initial response from the support team I was working with and also led to quicker turnaround time on the PMRs I submitted. While I cannot guarantee that the PMR turnaround time will be significantly improved, it should at least reduce multiple communications regarding the configuration of an environment. The main reason for back and forth about version information that I have seen is that the support team assumes the information provided will be all that is initially required to work the problem. While working and researching the issue, we may come to find that we need some additional version information (think operating system, 3rd party tool versions, etc...). Having the information up front when you open the PMR should prevent this from happening.
What I, and the rest of the IBM TRIRIGA Support team will do is look for this information on any new PMRs. If the information is provided in the PMR, we will check to see if the information has been stored on a customer record that we have set up in a tool we share with our L3 engineers. If you provide information and that customer record is not up to date, the engineer will update the information based on what was provided when the PMR was opened. If the information is NOT provided in the PMR, the engineer should ask for all of that information. I know that several of our clients are already familiar with that process and are providing that initially. We will do our part to smooth this part of the PMR process.
If you found this information helpful, please be sure to "like" it and be on the watch for my next blog regarding deployments.
GiuCS 270003E2P0 Visits (9700)
You are glad that after connecting your Eclipse BIRT environment to your TRIRIGA Database, and using a SQL Query you build your own very first report.
You preview it in BIRT and the report runs just fine, pulling data from the database and displaying within the format you set. It is a good looking report you think and my users will love it!
Now it is time to see it running in TRIRIGA, so you read the instructions that say you need to import it to Document Manager as a ZIP file to be used in a System Report running an External Query, and you think: Easy!
You get back to Eclipse and export the report. There are a lot of options to export it and you go for the "Archive File" one, that gives you the option to select as a zip what is the exact file you need to upload to TRIRIGA Document Manager, how convenient.
You import it to TRIRIGA, create a System Report, point to the zip file you imported to Document Manager and the report does not run, throwing an error in the front-end. Depending on the browser it could be an HTTP 500 error or a MID-xxxxxxxxx error.
What could be wrong?
Well, although BIRT Eclipse gives you the convenient option to export the report as a zip file, that zip file will preserve the folder structure from your Workspace panel (usually on bottom left of Eclipse Report Designer view).
TRIRIGA needs that the .rptdesign file inside the zip is located on the zip file root. If not, the report will not run. See the Bad and Good examples below:
In case you set the BIRT Flags in the Admin Console - Platform Logging and reproduce the issue you will see an error in server.log like this:
2016-04-18 13:11:04,682 ERROR [com
A very amicable message in the logs!
GiuCS 270003E2P0 Visits (5578)
Well, you get TRIRIGA 3.4.2 or later to install and see how cool to use the Liberty Profile for WebSphere Application Server (WAS). This lets you install both the web server and TRIRIGA at one strike and self deploys itself from TRIRIGA installer. What an easy deal!
After installing TRIRIGA and the WAS Liberty profile, the user logged into the service and running it cannot log out or the service will be stopped. Many businesses do not allow an Admin user to be logged in indefinitely.
Now you're thinking you have to install all over again in a WAS deployed first. You double check and see WAS Liberty cannot run as a service as a product limitation. What a drag...
Well, there is one workaround you can try. Using the Apache's daemon you can create a Windows service. The following instructions are an idea for how you can implement it, but it depends on your architecture and installation:
Note: If you run into any issues, check the logs in the LogPath directory location for any errors - the errors as listed in the event viewer logs from Windows do not give meaningful errors.
There is an RFE to implement this and I encourage you to vote for it: