ScottRuch 270004QNFJ Visits (9756)
When starting as a new user or working with a new copy of the application, there are some dependencies within the application that need to be satisfied if you want to do anything more than create a user record. In short, a newly created application has a good bit of data in it, but you will need to add more to begin using all aspects of it.
Do you want to add a Location? You'll need a Geography to assign to it.
Do you want to add an Organization? You'll need a Primary Location.
Do you want to add People? You'll want a Primary Location and Organization
The best place to start is in the Portfolio menu. Geographies, Locations, Organizations, and People form the basic building blocks for adding record data.
For Geographies, It's helpful to add at least two complete branches, one in North America and one for Europe. A basic scenario would begin with World Regions for North America and Europe and continue to City level for each branch. This allows for flexibility in scenarios involving multiple time zones, moves and other time and place based events.
2 - Locations
For Locations, in following the North America/Europe theme, it is sufficient to create two complete Location branches, much like Geography. As above, create complete branches beginning with Property and working all the way down to at least one Space record for each branch. This allows for flexibility in Space area calculation. Moves, and can also be used for Requests.
3 - Organization
There is not typically a need for as complex a structure for Organization. It is certainly possible and some scenarios will likely require it. but for basic testing purposes, a single My Company record, and a single External Company will be sufficient.
4 - People
As with the Organization structure, the users needs will dictate what should be created. Two users for the My Company record, and two users for the External Company will allow for basic testing. Remember that unlike the other records mentioned here, People have dependencies for Licenses and Security.
The linked IBM TRIRIGA Quick Start Guide will be of use.
Finally, I hope to open a dialogue on this topic so if you see this post, and you have a question please do not hesitate to ask, and we will provide you answers.
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 (8228)
This is for those of you who have more than 1 application server setup!
After spinning off the TRIRIGA application server into 2 separate application servers you are checking all to see if the second application server is set as the original one, the Licenses in the second application server show 'No' in the Licensed column in Administration > System > License, but the licenses have not expired.
First thing you try is to use a user id to log into this application server. There is no problem in the front-end application, any users can log into both application servers.
This was observed before as a cache issue. Sometimes during installation of a second application server the licenses at first have a problem fetching the correct status from the database and this information gets stuck into there.
What you need to do is to go to the Administration Console and Clear the Global Cache. Log back into the application and check the Licenses again. In most cases this is resolved as it is just a misalignment from the actual database information and what is cached.
If not, contact IBM support.
More information about cache clearing: How
Chris K 270004Y3TR Visits (8678)
If you have run into an issue while deploying the IBM TRIRIGA application in any of your lower environments (UAT, DEV, TEST), then you may have seen the Support engineer asking questions regarding your deployment window. In truth, we would rather have this information in advance of any production deployment, regardless if you have run into an issue that you report to the IBM TRIRIGA support team.
There are three reasons why it is important to get this information to the TRIRIGA support team. First, we may know of some potential issues that may crop up during the upgrade process, regardless of whether you are performing an application upgrade versus a platform upgrade. Second, when you have open PMRs with the TRIRIGA support team, those that could potentially impact your go-live timeline will be viewed with a more critically eye with regards to defects and the versions of either the application or platform. In both of these cases, there is a strong potential for a change in your implementation timeline. In the first case, the potential issues may require you to upgrade to a later release where the problem was resolved. In the second case, you may have identified a previously unknown issue that cannot be resolved with any existing releases and may require a fix pack release to the application and/or platform release to which you are upgrading. The third reason why it is important to know your implementation timeline is to insure resources are prepared to respond during your production roll out. While the support team is prepared to respond on a 24/7 basis regardless of any implementation schedules, we need to insure that development resources are aware and also prepared should a problem occur during your production implementation.
Just as you would rely on your internal resources, the TRIRIGA support teams are also resources on which you need to rely during your upgrade processes. Keeping us in the loop early on in your process will allow us to work with your implementation team as a single team rather than a separate group with whom you only need to tap when an emergency arises. Our early involvement is meant to prevent such emergencies and make the upgrade process proceed as smoothly as possible.
In the weeks ahead, I will be generating communication templates for the TRIRIGA support team to insure we begin to get deployment information from you, our customers. It is my hope that this blog provided you with sufficient insight into why this information is critical to your success during the upgrade process.
Chris K 270004Y3TR Visits (9573)
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.
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.
Chris K 270004Y3TR Visits (10206)
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.
doboski 310000SJR4 Visits (7637)
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.
GiuCS 270003E2P0 Visits (9620)
There are many reasons and installation scenarios that can cause Report, specially BIRT ones to fail to export due time out.
Excel exports are often the ones you can observe because all the file formatting happening during export.
Let's focus on Liberty installations, but this recommendation can be used to other web server with some tweaks.
Most of the times this is related to time-out settings, specially for HTTPS (SSL/TLS) connections. A good troubleshooting is performing the same in a HTTP connection, does the report exports? If so, take note of the time you need to export it and plan to extend time-out in HTTPS connections to at least the double of the time.
This is documented in the HTTP Endpoint entry in Liberty Knowledge Center link below:
Look for the sslOptions and also double check the ones for http, all time-outs be equally increased.
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.