doboski 310000SJR4 Visits (9441)
When TRIRIGA discontinued using JBOSS, many clients lamented over losing a light, low cost but efficient application server for running TRIRIGA. In its' place came WebSphere Liberty, a lightweight version of the traditional WebSphere application server. Starting with TRIRIGA release 3.4.2 in the summer of 2015, WebSphere Liberty is now packaged and shipped with TRIRIGA and can be installed through the TRIRIGA platform installer. Now it begs the question, what is the difference between full blown traditional WebSphere and WebSphere Liberty and why would I use one over the other?
Traditional WebSphere is a full blown application server with many features including deployment manager, node manager, and administration console functionality. Usually, companies who deploy it have a dedicated team that has the knowledge of Traditional WebSphere and has support for it. For smaller operations or organizations without WebSphere knowledge, the software may be too complex and too expensive to run. Given the large, complex nature of Traditional WebSphere, it can take a long time to even install it. Even longer if you are using multiple servers because you need to install WebSphere on each server you are using. TRIRIGA only needs a small portion of what WebSphere has to offer and does not support some of the more complex functionality anyway. So if you do not need something on that level, why use it? Why not go for the simplified version?
WebSphere Liberty is a light weight version of Traditional WebSphere. It does not have nearly as much overhead, nor does it require a dedicated team to install, run and support, like its' bigger brother. The beauty of Liberty is that comes with TRIRIGA and is very easy to install! Not to mention it does not take long to install compared to Traditional WebSphere. The TRIRIGA installer includes Liberty so when you run the TRIRIGA install, you have the option to install Liberty without any additional files. When you select Liberty in TRIRIGA, it makes the process seamless. There is no console to worry about. Liberty has all that TRIRIGA needs to run. After the install is complete, all you do is start up and batch file and you are up and running.
I bet you might be wondering; I need to use Traditional WebSphere because we are using SSO and I may not be able to use Liberty? Au Contraire. You are able to configure TRIRIGA 3.4.2 and greater on Liberty with Microsoft IIS and Active Directory. For details on that, I will direct you to this wiki for information on that.
Can Liberty be setup as a service like Traditional WebSphere? This is a bit more complicated and I encourage you to check out a colleague's blog entry on this subject.
In the end, you need to decide what will best suite your needs. In some rare cases, Traditional WebSphere maybe the way to go, for example if your company has a dedicated WebSphere team but in most cases, Liberty will work best. It's good to have options and know what the benefits are. To help you understand the benefits, you may want to look at this wiki page.
We sometimes hear in support, that TRIRIGA performance is slow. No other details are given. That doesn't help us out a lot. We need to know more, like what was going on at the time that? Is it impacting the entire system or just one area?
Performance of TRIRIGA is a bit complex. and there is rarely any one thing that can be done to improve performance. Performance can be impacted by hardware, network connectivity, software versions, queries, indexes, customizations, configurations and more. The answer to performance concerns is often solving some combination of these things. But some things can be reviewed to help point you into a direction where to look and what to do.
Some things like hardware and network connectivity are out of our control and need to be reviewed by your own IT department or a business partner to perform a health check or performance analysis on your system. We do provide a list of minimum hardware requirements that TRIRIGA should be running on in our installation guides. We also have a compatibility matrix to show you what configurations are supported for your particular version here: http
To help diagnose the problem, TRIRIGA has performance logs that can be enabled, retrieved and analyzed. There is a wiki page that describes the process of enabling the performance log files as well as analyzing them, which can be found here:
The wiki will walk you through how to enable the performance log and then analyze the output.
In case of performance concerns, TRIRIGA Administrators should ALWAYS review best practices to ensure they are following recommendations before entering a PMR. The wiki regarding Performance can be found here: http
Once you have the performance log, you can create the following pivot table to help identify where something is taking too long.
Generally, if something is taking longer than 10 milliseconds then it is taking too long to. For instance, in this example, you can look at the query for the report and see if it is optimized correctly. You may need to look at your database to see if anything needs to be adjusted at the database level.
It should be noted, that if you are using multiple servers in your environment, you would need to access the console from the server that is having the problem. If you have 3 UI JVM's and 2 process servers, where one of them is the workflow agent and you know you are having issues with workflow performance, then you would access the console from the server that has the WF agent running.
So using the performance log can help you identify what could be taking so long and if you enter a PMR that is something that can help us out as well. It is important to remember, that TRIRIGA Support is committed to every clients success, however; performance is not typically covered as part of the support agreement. Our goal will be to help point you in the right direction but since most performance inhibitors are unrelated to TRIRIGA, the support team cannot commit to resolving performance related issues. We may advise you but the resolutions are often up to you.
JeffLong 270005B0Q4 Visits (10511)
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 (9553)
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.
JeffLong 270005B0Q4 Visits (8248)
If you are getting an error message that states, “Current browser does not support native SVG.” Internet Explorer 11 64bit (IE11) does support native SVG as delivered.
Customer tested with Firefox and did not get the message. However, when the customer tests other environments at their location with their IE11 browser native SVG works ok.
The conflicting tests of IE11 working on other environments and FireFox working in the environment where IE11 does not makes this tricky to troubleshoot. We will use a test SVG file to test the browser locally and then test the SVG file on the web server to see if it works from both locations in IE11. If the file will test ok on the local PC, but fails on the web server, this indicates a web server configuration issue.
First, create a simple SVG file for testing. Simply create a new text document and copy and paste this into it”
Once this is copied into the file save the file to a known location on your computer and name it “simple.svg”.
Now, open your browser and find and open the simple.svg file that you created. If you can see part of a black circle in the top-left corner of your browser after opening the file, your browser should work with native SVG. The circle part will look something like the example below:
Testing the web server:
Place the same file that you tested on your PC onto your web server and using the web server url with the file location and name included, see if your browser loads the SVG file and if you see the circle part as you did in the previous test. If this test fails, you most likely have a web server configuration problem. If that is the case, please consult your web server vendor for help with configuring your web server to work with native SVG.
Fabio L Pinto 270003DRX7 Visits (10106)
When running IBM TRIRIGA Platform Installer, you may turn on LAX_DEBUG parameter for installer to run in DEBUG mode:
LAX_DEBUG=true <installer command line>
a) LAX_DEBUG, it is the parameter per si;
For Linux/Unix, use bash or sh shell for executing the installer using LAX_DEBUG.
For Windows, use command prompt / shell and make sure you use "Run As Administrator" right-click option when executing, so that administrator security rights is correctly set to the session.
The extra DEBUG log lines are printed out to the console, the ant.log isn't impacted. Copy and paste the console output lines as text so that you can better check the installer tracing information. It may be really useful when troubleshooting IBM TRIRIGA installer runs and this is part of the required information IBM TRIRIGA support would request for these cases.
What is the Tririga WF started for Schedule Event generated by a Payment Reconciliation from a Lease with Audit Clause?
Fabio L Pinto 270003DRX7 Visits (12175)
The Tririga workflow fired is "tri
This is how it works:
a) When a lease is activated, This workflow "triLeaseClause - Synchronous - Create Audit Service Included from Selected" is fired on Lease Clause to create Payment Audit Setup record.
b) Then the "tri
on scheduled start dates.
If you see no WorkFlow being started for the Schedule Events created for the Payment Reconciliation on Leases with Audit Clauses and you have Microsoft SQL Server in place, check if you have the following fix included on your IBM TRIRIGA Platform version:
APAR #: IV76293
If you are still seeing issues with this process and you can be reproduced on a lower environment (testing, sand-box, QA), it is good temporary set Workflow Instance Recording on this lower environment for tracing the Workflows & actions fired for the lease record, and check the flow and warning/error messages issued during the process. But see that using Workflow Instance Recording can cause slow downs and performance issues all over system, so it needs to be used only for lower environments (it should never be used for Production environments!) for temporary tracing and debugging workflows, meaning this needs to be changed from "Always" to "Errors Only" as soon as you are done with your analysis.
For more information on using Workflow Instance Recording, kindly review our
Fabio L Pinto 270003DRX7 Visits (11564)
a) triPeople - triRetire - Remove TRIRIGA User and Read Only Dependant Records
b) triPeople - Synchronous - Remove TRIRIGA User My Profile
This move the record to Retired state, meaning they are still retained in the system. The only transitioning able to remove them from the database is setting them to NULL.
Each People BO record occupies 50 KB in average, so if you are performing massive deletion, for instance, deleting 100,000 records, this means about 5 GB being processed and worked by triRetire process at that time.
Using triRetire is the only supported process for archiving triPeople BO records.
If there is need to perform a massive retire process in system, Data Integrator may not be a good choice. Using WebServices will be a better option, but this could be enhanced to look at the number of workflows in the queue by looking at the "monitor.jsp" - Monitor a single value.
The web service code would parse and check for the numeric value returned from a URL like http
If the value is over a number (start with 9000 for example) then it would pause the integration and wait for a while until the queue is halved (4500 for example).
See that there isn't a direct way to call a workflows using WebServices. You would cause it to be executed for a given record by performing the action(transition) on the record that the workflow it tied to. For instance, if you have a workflow tied to an 'Activate' action, then using the WebService to activate the record will cause the required workflows to execute.
More information about IBM TRIRIGA WebServices can be found on our
"You do not have permission to access this page" error message when the requester tries to open a service request record sent back from the approver for clarification
Fabio L Pinto 270003DRX7 Visits (10771)
If you have a Tririga user creating successfully a service request record that goes to approval workflow, but the approver sends it back requesting clarification, you may receive a error message saying "You do not have permission to access this page. Please, contact your TRIRIGA administrator. Thank you.".
This may happen when that user only has "TRIRIGA Request Central" license assigned to him/her.
If this is the case and Security Group setup allows that, the user can successfully create the service request record that will go through the approval workflow, and that license will allow action Notification. But if the record is sent back by the approver for clarification this will require access to action Item Record Type (Wor
Here it follows the list of the IBM TRIRIGA Licenses providing access to the action Item Record Type WorkFlowActionItem:
IBM TRIRIGA Facility Management Enterprise
The solution for that error will be adding to the requester user any one of the licenses above so that it is possible to process the WorkFlowActionItem action properly, as per design. The rest of security will rely on the Security Group setup for that user, and so you can restrict access to any BO or Form as per your business needs & requirements.
Bill Cary - IoT 060001Y279 Visits (6658)
If you’re a TRIRIGA user, by now you know some of the great features of this plat
Our most recent platform release more fully embraces HTML5 and reduces the number of Java Applets used which have many client computer implications. Of course it includes some code fixes and enhancements too. The result is not only improved functionality but the ability to use a wide array of current browsers including IE, Firefox, Chrome, and Safari. All of this brings value to your implementation of TRIRIGA and we strongly recommend adopting this new TRIRIGA Platform.
To get the most out of TRIRIGA, you will need to upgrade your applications as well. Although, older applications will continue to run on the newer platform, the new functionality built into newer applications will not be there. While there are many benefits to upgrading just the platform, there are many more when you upgrade both your platform and applications (note, you cannot upgrade applications beyond the level of the matched platform level).
One last but certainly not least reason to upgrade is supportability. IBM TRIRIGA makes every effort to stay current with its supporting technology but as the technology business changes at an ever increasing pace, we can only support our products on the technology they were built on for so long. Generally, we try to support our products for 5 years but there are sometimes reasons beyond our control that cause us to end support for products earlier than that. When End Of Support (EOS) is eminent, we work hard to notify clients many months or even years in advance. All clients and users should sign up for notifications on any IBM products you use at the following link:
The table at the link below shows products that have already reached EOS as well as the list of products we currently support. Note that IBM is unable to accept PMRs on products that do not have a support agreement that covers them. As of today, all TRIRIGA Platform versions prior to 3.3 are EOS and all applications prior to 10.2 are EOS.