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 (11533)
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 (10888)
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
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:
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.
ScottRuch 270004QNFJ Visits (10390)
When TRIRIGA got started, the entire focus was to leverage web-based tools to improve process in Capital Projects. The short version was ‘stop sending data to everyone and start bringing everyone to the data. This allows the entire project lifecycle to be captured in a more portable way. The benefit to the contractor is savings in time and money via improved communication and greater procurement visibility. The benefit to the owner and end users is better information about what was done during the project, when and why.
Over the years, we have added an additional layer on top of the TRIRIGA project record type called “Program”. This new layer allows for greater funding control across projects and fits neatly with the observed behaviors of the majority of our institutional and government clients.
Understanding the value of project management is key to gaining value from the TRIRIGA Projects module. At the heart of a project, budgeting and task data are captured during the entire project lifecycle, allowing a given user a view into the pulse of the project. This information allows for more informed, more timely, decisions for both tasks and resource allocation. In addition, this real-time capture of plans vs actuals enable a clearer view of budgetary trends. Even more capability includes secondary functions, such as permitting, design control / validation, and formal risk management.
TRIRIGA Projects was developed and driven by necessity and has evolved into a powerful solution to capital project management that most organizations cannot live without.
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:
GiuCS 270003E2P0 Visits (10251)
A common question in a new installation is where is the Real Estate Lease Abstract Offline Form as it is not in the Lease Abstract Offline in Tools Data Utilities?
Why is that so?
When you have a new install and you go to the manual to follow the instructions how to use the Real Estate Lease Abstract Offline Form the instructions point out that you must navigate to the Tools -> Data Utilities -> Lease Abstract Online and work with the Real Estate Lease Abstract Offline Form there.
But when you do so, the list is empty... Is the Real Estate Lease Abstract Offline Form a separate download in Passport Advantage or IBM Fix Central you might ask.
Not really, the Real Estate Lease Abstract Offline Form is indeed in TRIRIGA, but in another place.
The form must be downloaded first, and the spreadsheet populated, check out how:
There you go, a fresh new form out of the oven for you
ScottRuch 270004QNFJ Visits (9939)
How To: Reassign Pending Approval Records for a Person in IBM TRIRIGA
A person could leave a company or an organization for various business reasons including termination, retirement, layoffs, new job role / promotion in a different organization, or departmental re-organization. In the IBM TRIRIGA, this person (user) could have pending Approval records in the system that needs to be reassigned. IBM TRIRIGA has a process to address this business need. It can be accessed from the menu: Requests > Manage Requests > Other > Reviewer Admin.
The “Reviewer Admin” form allows an admin user to reassign the Approval records that are pending the person leaving the organization. On the form, the user will select the ‘Currently Assigned To’ person and the ‘Reassign To’ person then click ‘Create Draft’ and ‘Issue’ to process it. Then, processing occurs to update the ‘Currently Assigned To’ person’s Approval records to indicate each has been reassigned. The system also creates a new Approval records and assigns to the ‘Reassign To’ person. Standard request processing continues and it completes the Reviewer Admin record. At this point, the ‘Reassign To’ person has pending approvals assigned to review and take action on.
In summary, the ‘Reviewer Admin’ functionality in IBM TRIRIGA assures that pending approval records are not lost in the system when the business situation of a person leaving the company or an organization occurs.
Reblogged from the TRIRIGA Wiki:
JeffLong 270005B0Q4 Visits (9931)
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.
doboski 310000SJR4 Visits (9855)
Managing your security groups in TRIRIGA
There are some things to know about managing your security groups in TRIRIGA. Out of the box, TRIRIGA comes with pre-defined groups based on various roles. You might be able to map one of your roles to an existing security group. But if you have a need to make additions to an existing group, then it would be best to copy the group that it closely resembles. Then you can modify it for your needs. It is best to know what out of the box groups offer and what your needs will be. Then you can determine if you can use an existing one or create a new one. It is a best practice to copy an existing group and make changes to the copy if you need to remove or add access. This way if something is not being granted correctly, you can refer to the out of the box role to see if the problem still occurs.
It should also be noted that you do not have to define one giant security group if you have a user who might have multiple roles. For instance you might have a user who is a Lease Manager but might also have a role with Facilities Maintenance. You would associate the user to 2 different security groups – one for Lease Manager and the other for Facilities Maintenance. This way, if you end up with security issues, the best way to troubleshoot them is to remove groups until there is 1 associated to the user. Test. Then remove that group and add another one.
The exception to coming security groups is the Administrative group. This is a group that should not be copied. This is because it is a special group with special privileges. Copying this group would not copy all the privileges. You can certainly add users to this group. But as mentioned, this is a special group. You might not want to have all users in this group. Instead, you would want to consider putting your Administrative users in the TRIRIGA Application Administration group. This group has most, if not all Administrative privileges that would be needed by an Administrator.
If you do have a need to create your own security group, then it is best to first map out the access that you want it to have. See if there is an existing group that resembles what you are looking for. Then copy it and modify to what you need. Copying an existing group and then modifying is certainly easier than creating a new group scratch.
Another important note regarding managing your security groups is defining if they are specific to a specific organization or geography. Depending on how widespread you use TRIRIGA, you could have your data defined across multiple organizations and geographies. You could have Lease Managers in different organizations and geographies but they would not want to see each other’s data so you would have a Lease Manager role for each organization. But there might be some people in a role who would want to see the data across multiple organizations so then the group would have the same access but the organization and geography level would be one level higher to incorporate children in the hierarchy. Once you have defined System Organization and System Geography, then only records that have those fields defined can be accessed. So you need to be careful with the data and access. It is important to note that your group structure can be difficult to manage if your groups combine System Organization, System Geography and application security in the same group. The best practice is to use multiple groups and layer groups for each user.
For example, Group 1 defines System Organization security as \Org
For more information regarding System Organization and System Geography please check out the wiki
After creating or modify your security groups, it is a good practice to go into the Admin Console -> Cache Manager and clear the Security Scope cache.
Chris K 270004Y3TR Visits (9699)
Have you upgraded your IBM TRIRIGA platform only to find that you cannot see any of the graphics that were visible in your previous platform release. If so, you may want to reprocess your drawings.Please note that reprocessing your drawings can take some time, so you might want to plan this process to run during off peak hours.
To reprocess your drawings, follow these steps.
1 - As an application administrator, login to the IBM TRIRIGA Admin Console.
2 - Click on the radio button next to Database Manager
3 - Click on the link titled "Reprocess published drawings".
Under certain conditions, the reprocessing of your CAD drawings may have encountered issues during the upgrade process. It is important to always review the server log file from the 1st server startup after an upgrade. In the case of your drawings, look for "Reprocessing" in the log file. Most of the entries after that line will contain information about the reprocessing of each individual drawing. If a drawing is processed without issue, you should see a series of 7 informational messages starting with "DXF: Processing Header "to "DXF: EOF" if there is a problem during the reprocessing process, you will likely see either an error or warning message between those two informational messages. If that is the case, you will want to follow the steps outlined above once the upgrade processing has completed on that 1st server.
AcdntlPoet 2700019V2G Visits (9692)
Now THAT is a great question! IBM Watson IoT Support is a team of IBMers who are now part of the new IBM Watson Internet of Things organization supporting the tools makers like you need to build components and connected devices. IBM Watson IoT Support is focused on helping you, the makers, with your product questions by providing content relating to the various products covered by our new division.
Through our focused support of asset management and continuous engineering tools, we are here to provide you with the best support in the industry; to help you be successful with the applications and components to ensure your work on the connected devices in the Internet of Things brings you the right value.
The products we support here include:
There's no change in the way you will obtain support for the products you already own, the only change you'll likely see is the addition of a few new social channels like this blog, our new Twitter account, and our new Youtube channel to help get you the right content at the right time. Our technotes can all be found in their same locations per product, and the process for contacting support to open a Problem Management Request (PMR) remains the same as well.
doboski 310000SJR4 Visits (9682)
Towards the end of last year, I had the opportunity to sit in on a Maximo Anywhere class. While I am a TRIRIGA Support Engineer, both Maximo and TRIRIGA use the Anywhere platform for their mobile solutions. So for me, there was benefit in sitting in on the class since the process of configuring is the same for either product though the code base will be different! So these tips could apply to either Maximo or TRIRIGA, depending on what you are using. It is worth noting that Maximo has more mobile applications than TRIRIGA. So I would like to share with you some basic tips that I learned in this class.
As shown in the screen above, there is a section called Outline that will, like the UI, view sections of the code. When you click on something in the outline, it will bring you to that section of the code. Which will save you from having to search the code for the correction section. Believe me, I am wishing I used that to help me find the Work Detail View as I ended up putting the new field I was trying to add in the wrong place! But I learned my lesson!
So those are some basic tips when getting started with configuring your Anywhere files. I hope this will help you get around easier when configuring your Mobile solution, be it on Maximo or TRIRIGA. And remember tip #1 and #2 - ALWAYS back up your files! Save early and save often!
GiuCS 270003E2P0 Visits (9673)
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 (9623)
It is often asked if there is a panel or administration console available in IBM TRIRIGA for showing active users and the licenses they are consuming.
Unfortunately there is not, but to circumvent this you can use some helpful SQL queries.
The SQL queries are documented in
The queries provide a snapshot of current user and licenses being used, in a few different outputs: