

When CAD Integrator gives you a Syncing feelingThe IBM TRIRIGA CAD Integrator tool is extremely helpful in many client environments. For many clients, the space records are created and managed via the CAD drawing which means that errors during the process could seriously hamper your productivity. Today I will review one particular error and describe how you can use the information in that error to start your own investigation into the issue.
Below is an example of an error that can occur during the Sync Full process in CAD Integrator. Values in the error have been changed to be generic, your error message will contain numbers specific to your database. 2016-05-20 11:04:51,738 ERROR [com
First, read the message so you can get a general idea of the problem. There are two key parts of the message which will give you a general idea of what is happening. You can see that the sync process failed. The information immediately after "Sync failed." provides information for the developer to identify what path within the code raised the error. After that path information is a more critical piece needed to do further analysis. Specifically, there is this in that error message: "Attach associated object could not find the association to use." From this information we can see that the sync failed because it appears that one of the objects is missing an expected association to another record.
Next, we are going to get into the details of the error.
The first value, SSSSSSSS, is actually the spec_id for a triSpace record. You can use that value to query the IBS_SPEC table to determine the name of the space. The SQL statement to find this information is: select * from ibs_spec where spec_id = SSSSSSSS
This will display all of the fields in the IBS_SPEC table. Besides the name of the space, you will also be able to see the location information which will allow you to get to the underlying record in TRIRIGA.
The next value, PPPPPPPP, is the spec_id for the triPeople record. We can then reuse the select statement above by simply using the PPPPPPPP value rather than the SSSSSSSS value.
This will give you the information you need to look at the associations that are on the space record as well as the people record. If the Sync Full process does NOT fail on a different drawing, you could use a space record and associated person record from that drawing as a guide to determine the missing association. You should then be able to create the required association and run the Sync Full process again. It is important to note that the Sync Full process is more inclusive than the Sync Area process with regards to the various records associated to the space. If Sync Full fails and Sync Area does not, then you will need to review the error in the ci.log file as described in this blog post to determine the records that are causing the error to occur. Tags:  ibm-tririga iot-support #ckrajec #l2support supiwms ibm-iot |
What does support mean when they say 'As Delivered'?
First, some fundamentals. IBM TRIRIGA is actually comprised of 2 components. There is the application version (eg 10.3, 10.3.1, 10.4, 10.4.2.1, etc.) and there is the platform version (eg 3.3, 3.3.1, 3.4, 3.4.1, etc.) It is important to understand the difference between the two versions. The platform version is the base upon which the application version is built. This is why you could not have a 10.4 application version running on a 3.3 platform. For a 10.4 application, the platform must at least be 3.4. The only exception to this is with regards to the 4th numeric position of the version number. It is possible that there is a fix pack for the application only and no changes were required of the platform to implement that change. Another way to keep the application and platform versions straight in your mind is to remember that you can customize the application, but you cannot customize the platform.
Second, there are several tests the L2 engineer may perform while trying to replicate an issue. The first thing is to test to see if the issue exists in a later application release. Often this means that we are also testing with a later platform release. As mentioned previously, the only exception is if there is a fix pack for the application only, no platform fix was required to implement the application fix. The L2 engineer should also check to see if they can recreate the problem using the same application version as you. This means that we may be testing with a platform release earlier than the one you have in your environment. This is where we start getting into the realm of the As Delivered terminology.
Suppose you have a problem with your application and you know that your base version is 10.3, You may have customized the application, but the basis of that customization was the 10.3 application version. Based on this scenario, the L2 engineer would test with an environment that is on the 10.3 application AND the 3.3 platform. This is what we mean when we say "As Delivered." The installer for the 10.3/3.3 IBM TRIRIGA Application Platform when installing a new environment would result in an "As Delivered" 10.3/3.3 environment. In you environment, you may have a 10.3 application, but you may have a 3.4 (or later) platform. If we could not replicate the problem in an As Delivered 10.3/3.3 environment, we would then check to see if we can replicate the problem in a 10.4/3.4 As Delivered environment. If we cannot replicate the problem in that environment, that would be a strong indicator that the problem may have been resolved in the 10.4 application code. If we can replicate the problem in that 10.4/3.4 As Delivered environment, then it is possible that the platform code introduced the problem.
Now that you know what we mean by "As Delivered", you might want to consider creating some small environments that represent an As Delivered state based on your application version as well as your platform version. In a future blog, I will talk about the importance of setting up these types of environments.
Tags:  #ckrajec iot-support ibm-iot ibm-tririga #l2support supiwms |