I am new to the IBM TRIRIGA Support organization, working as a Level 2 Support Engineer. It has been my observation when reviewing PMR's that there is a lot of time spent going back and forth between the customer and the support engineer. It seems to me that this is due, in part, because not enough information was initially provided. Many times I have seen, in a PMR, that the customer is getting some error. Sometimes they just say they are getting an error or they may report the specific error with no information about how it happened, what version they were using or what they were doing. Many times there are vague steps with our client thinking that TRIRIGA engineers should know what they are trying to do.
I wanted to share what happens in support so that clients might understand why information about a problem is so important. When support receives a PMR we try to reproduce the issue based on the information given to us. If we are not given enough information, we are forced to collect it by making requests that can take days or even weeks to accomplish. Time zones play a role where each email can take a full day to get to the right people and get a response. In some cases, if we are provided with not enough information we may fail to replicate the problem which does not mean it is not an issue, it just means we may have replicated incorrectly because we are missing information or there are configurations or customized workflows that we do not have. There could be something in the way that the customer is doing something versus how the support engineer is doing something, because with software, there can be more than one way of doing something. If we need to get additional information it just takes that much more time.
We recognize that your time is valuable and it can be frustrating going back and forth to get the necessary information to reproduce an issue. What would help us in IBM TRIRIGA Support, is when entering a PMR, clients provide detailed step by step instructions as if you were asking your non tech-savy grandmother to reproduce. It may sound corny but it really is all in the details. As I mentioned, there could be more than one way to do something and left to our own devices, we might not do it the same way as you (the customer), so the more details the better.
If you have ever cooked and followed a recipe you are following steps. You might think of that approach for entering your steps to reproduce an issue.
Your time is valuable and we recognize that. The more detailed you are with your initial entry on the PMR, the less time spent going back and forth trying to get the steps and more time can be spent on reproducing and resolving your issue.
Remember, we do have a document we often call a “Must Gather” or “Information To Collect” document for TRIRIGA PMRs. You should always submit this when you open a PMR. You can generally fill it out and save it so you always have it handy to attach to PMRs, just remember to update it when something changes. See it here:
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:
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.
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.
Where documents go when they are uploaded may not make a difference to the average user as long as they are uploaded and can be viewed. However, to some people, where they get uploaded to does make a difference. Do they go into named folders or do they go elsewhere? Where do the files go when they are uploaded?
Where a document goes is determined by the context of the record. How does one tell what the context is? The context is determined by the 2 “buttons” at the upper right hand corner of the main portal screen for Company and Project, as shown below.
If you select Project, which you can see by the screen shot below, it shows the project name, when a document is uploaded, it will go into a named folder as shown below.
If you select Company, then it will upload into a file structure like the screen shot below illustrates.
So if support ever asks you what the context of the record is, it is referring to those 2 buttons at the top of the screen: Company or Project. We are looking for where your document went. You will not see those folder structures unless you are in Document Manager. And in many cases, users are not going to have access to Document Manager so they will not have access to it. Overall, it is good knowledge to where your document is going so if problems arise, you know where to look.
dmmckinn 1200006SCS Visits (1233)
Date: Monday, April 29, 2019
Time: 11:00 AM Eastern Daylight Time
Duration: 1 hour
Join this webinar to hear how IBM’s TRIRIGA platform is a key building block to allow Facilities management and Real Estate organizations realize their strategy of smart workplaces. Through business analytics, critical alerts and automated process capabilities, IBM is helping our clients increase visibility, control, and automation of their real estate management, capital projects, space management, facility maintenance, and energy management needs.
Register to attend!
dmmckinn 1200006SCS Visits (1508)
Attend IBM IoT Exchange 2019 to learn how industry-tested solutions from IBM and our partners have solved the most critical IoT challenges facing companies today. Much like a university, this unique event will be structured into four dedicated academies:
Register now to attend!
dmmckinn 1200006SCS Visits (2705)
This year’s TRIRIGA user group conference spans all aspects of the facilities, real estate, and building lifecycles – delivered by clients, partners and the IBM product and business teams. See partner and IBM demonstrations, and speak with product experts to deepen your understanding of the capabilities available to achieve greater ROI for your business.
Here are 6 key Reasons to attend TRIRIGA University:
Register now: http
dmmckinn 1200006SCS Visits (3797)
Companies are instrumenting and connecting their industrial equipment, buildings and facilities, and vehicles with billions of sensors to create what is known as the Industrial Internet of Things (IIoT).
To learn more, read Industrial “Things” Produce “Industrial-Sized” Outcomes, by Kareem Yusuf, General Manager for IBM Watson IoT.
jendobo 50V7SQF9N1 Visits (5533)
Have you ever wondered how to import a new fiscal calendar into TRIRIGA? I have wondered and recently went through the exercise of loading a new calendar. So I will share my thoughts with you. Keep in mind, Classifications are hierarchical,
First, you need to go into TRIRIGA, to Classifications and add a new Fiscal Period. You can do this manually. Once that is entered, you then work with your import files to get them in the correct format to then use Data Integrator to load into TRIRIGA. When working with your import files, they need to be in a .txt format. However, in order to make sure the formatting is correct, you need to edit them in Excel and save it as a .txt file. If you don’t, it could cause problems when you load the import files. Before loading, you should create the Fiscal Period manually. This will be used in the path when loading fiscal years, quarters and months.
Note: before loading your data, it is always a good idea to load a couple of records to make sure it loads correctly and in the right spot before loading everything.
Starting with Fiscal Years, your import file would look something like this:
It has the column names in the header. Then you enter your data. You need to be sure that the path name is correct. Then in Excel, you would save it as a .txt file. Once you have your import file, you can go to TRIRIGA Data Integrator to load your file. When importing the file, it is important to make sure you have the correct settings. You want to have the Module set to Classifications. The Business object to Fiscal Periods and the Form set to Fiscal Years.
After you loaded your sample file, you should go to Clas
If there is an error, generally it could be something like the header was not correct. Or the path name of the Fiscal Period is not correct.
Once you have successfully loaded the fiscal years, you can then load the Fiscal Quarters followed by Fiscal months using the same steps above. Just be sure you get the correct path name and when you use Data Integrator be sure to use the appropriate form. And I recommend that you import a few records at each level to be sure that it will load successfully. If it loads under the wrong category incorrectly, then you need to manually delete those records which could be time consuming.
AcdntlPoet 2700019V2G Visits (7360)
Recommended better practices when using Lease Accounting Payments in TRIRIGA - Edgar Mengelberg discusses some simple steps you can consider that are seen as recommended best practices where it concerns your Lease Accounting Payment Schedule run. [Read more...]
More posts from Edgar:
See even more posts on the IBM Real Estate and Facilities Management blog
JeffLong 270005B0Q4 Visits (9006)
IBM TRIRIGA Support works on addressing problems through a problem ticketing system where each issue is logged as an IBM Service Request (SR) or Problem Management Report (PMR). IBM TRIRIGA Support manages problems reported via this process.
This page has a Support Resources Home section that provides numerous links to some great resources, including a link to our IBM Service Request system where you can open a Service Request (SR). For convenience, the link for creating a Service Request (SR) is here: http
Alternatively, on the IBM TRIRIGA Information and Support Resources page there are also IBM Support phone numbers that can be used to call for support.
Once an SR/PMR is opened, it can be tracked for updates via the SR tool. You may also request an update at any time and this will notify the Support team to follow up with you as soon as possible.
For the most efficient IBM TRIRIGA support experience, a few guidelines should be followed:
Also, it is important to have one problem per SR/PMR because if the problem reported is determined to be a defect, we will create an APAR for it and an APAR also can only cover one distinct problem and we can only create on APAR per SR/PMR. More information about SRs, PMRs, and APARs can be found here: http
Please keep in mind that if all issues are logged as severity 1 issues, this is a misrepresentation, and IBM will be unable to provide adequate timely resolution for truly critical issues for all customers.
Keep in mind that any inside knowledge about your particular problem or environment is good to provide as well because Support deals with a wide variety of issues and test cases and might not be aware of how a particular customer has customized their envi
Finally, try to be prompt and clear in your responses as we communicate during the resolution process. Especially with high priority issues. The quicker you can reply that you have received any updates and let us know your response, the better. Again, due to the large volume of issues coming in, by quickly responding it can ensure that your issue remains at the forefront of the minds of those involved.
For additional guidance on the IBM TRIRIGA Support process, please see the following link for our IBM Support Handbook: http
doboski 310000SJR4 Visits (9394)
In this day in age, security is a very hot topic and as soon as one vulnerability pops up, it is addressed and mitigated, another one is found. It is a vicious circle of identifying and addressing that does not seem to let up. In our fixpack release notes, information regarding mitigation of vulnerabilities that were addressed without an APAR is listed. And sometimes, a vulnerability could be addressed as an APAR.
The reason I am mentioning security vulnerabilities is that sometimes, when they are resolved, there is an effect that impacts existing functionality and it may not always be clear. Sometimes, the result of fixing these vulnerabilities can “change” functionality.
As an example, in the 3.5.2 release, there is mention of an APAR related to external URL navigation items will now open in a new window to avoid cross origin scripting vulnerabilities. Prior to the 3.5.2 release, if you used an external URL in the navigation, it just opened in the same window. We have seen some issues where clients wanted the original design, but that is no longer possible since the change was made as a result of fixing a security vulnerability. The current behavior is correct and cannot revert to the old design. So in this case, there was an APAR referenced. But in others, there may not be. You can look at the 188.8.131.52 release notes (found here http
As the product develops and security vulnerabilities are found and addressed, it could mean a change in how something works. Reading the release notes can be a source of information but it may not always be clear why something changed. We all know change is hard, especially when we are so used to it working a certain way. I don’t know about you, but if the change was made to address a security vulnerability, I can live with that and accept the change.
doboski 310000SJR4 Visits (9154)
If you are an administrator for TRIRIGA, chances are you have access to Security Manager, which is responsible for granting access to the TRIRIGA applications through the security groups. Prior to 3.5.2, the only way to view security access was to go to the Access tab and then select the Access Configuration sub-tab. That is where you would grant (or remove) access. However, it is not very user friendly in terms of finding something and looking what the overall picture of the access of the selected security group. So in 3.5.2, a new sub-tab was access to the Access tab called Access Summary.
The Access Summary tab will show you in a column format, the permissions of the module/business object, form, tab and section. You are able to filter by each of those fields. But only the module/business object and form filters will have a drop down list. The rest of the filters are free form text so be careful when entering data into them.
It is worth noting that when you go to the Access Summary, it will take a little bit for the data to come up. This is because of the query used to extract all that data. Once you have the data up, you can start using the filters to look at the access. what modules/business objects it has. Or if there is a specific form you want to look at. The permissions field will show the specific permission, if it's Read, No Access or the name of the action, like Asse
This tab should now make it much easier to identify what a security group has access to. If you find yourself limited with what you want to do within the tab, there is an Export button, that will export the data into a tab delimited .txt file. When you click on the Export button, you will get a message letting you know that it will run in the background and you will receive a notification when it is complete. You will want to monitor your Notification notices. It should also be noted that the file is exported to the application server, not your local server. The path of where the file can be found will be in your notification. If you don't have access to the servers, you will need to reach out to your system administrators to get the file for you. Here is what the file will look like when it is imported into Excel.
So there you have it - an easier way to view the access of a security group.
doboski 310000SJR4 Visits (6863)
In TRIRIGA's Data Modeler, there are 2 methods to add a field to your business object: Add and Find. How do I know when to use them and what really is the difference?
Add is when you are creating a new field that has never existed before. It should only be used for creating brand new fields that do not exist. This not only adds the field to TRIRIGA but it will add t to the database. For example, you want to add the field cstNewField1TX to the business object triContract and it does not exist on any other business object. So you would use Add to add the field.
Find is used when you want to add a field whose name already exists. For example you want to add cstNewField1TX to the business object cstMyObject. We know from above that cstNewField1TX was already added (and we will assume published). You would use Find to search for the field and it would add it to your business object, with all the same information. Then, it can be modified for this particular business object, except for the field name and data type.
If you are looking for a specific type of data - say a Start Date, you would use the Find action to look to see if a Start Date exists and re-use on your business object.
Why does this matter? Because, if you added cstNewField1TX to your business object, you could get errors because that field name already exists on a different object. It could cause confusion seeing the same name more than once in the database. Even if you remove the field, you are removing the field from TRIRIGA, not necessarily from the platform.