How do you rename forms without breaking CAD Integrator mapping?


I’ve made some modifications to a handful of forms that are connected to CAD BO Mapping records (e.g. triEmployee, triSpace, triFloor, etc.). I’ve updated the label to follow the traditional TRIRIGA customization standards and relabeled them with “cst” such as “cst-triSpace”. However, in AutoCAD, when I attempt to Smart Attach and/or Publish drawings, I get an error that seems to point towards the GUI Name of the form not lining up to the CAD Mapping. How do I get CAD Integrator to pick up the same form but with a different label?

When renaming those forms, you must make a few changes to the CAD backend:

  • 1. Create new CAD Mapping records that point to the new form. I recommend checking the old mapping records to make sure all fields are added properly.
  • 2. If you added any required fields, I believe that they need to be added to the CAD Mapping record.
  • 3. Open the CAD Hierarchy and make sure each node is pointing to the new Mapping record that you created from Step 1.
  • 4. Update the form on the CAD Label Style to point to the new form.

Note: If you are on a newer platform, I recommend keeping the form names as “tri”, and using object labels to manage versioning.

[Admin: To see other related posts, use the Integrator tag or Object Label tag.]

Continue reading

Advertisements

Why doesn’t TRIRIGA CAD Integrator complete the Sync Full process?


We’re unable to perform a Sync Full of CAD drawings if there are any people assigned to the spaces. Here’s the ci.log error:

ERROR [com.tririga.ci.sync.SyncServiceImpl](pool-1-thread-2) Sync failed.
com.tririga.ci.error.CiRuntimeException: com.tririga.ci.remote.shared.error.CiSharedException: Attach associated object could not find the association to use.

The CAD hierarchy for the custom configuration is not mapped correctly for triSubSpace. Custom business objects and forms were created for all property hierarchy items. But the existing triSubSpace CAD hierarchy node for triSubSpace was not changed. It still references “Space Mapping”, instead of “cstSpace Mapping”. This means both space mappings are part of the application definition (which have different forms). This was causing the Sync Full to fail. Updating the triSubSpace hierarchy node to point to the cstSpaceMapping will resolve this error.

[Admin: This post is related to the 09.12.16 post about a Sync failure in CI, and the 08.05.16 post about a Sync Full error in CI.]

[Admin: As a side note, with the 3.5.1 introduction of object labels and revisions, you’re not required in 3.5.1 or later to use the classic “cst” naming convention any more. For reference, here are the new naming convention best practices.]

Continue reading

Why aren’t service requests available after customizing form?


When submitting a Change Space or Need Space request, I see the following message when I click on the Create Draft button:

“No services are available under the Service Request section for the building. Please contact the Application Administrator.”

If you look at the triBuilding form, it does not appear to have a “Service Request” section. Where should I be looking on the building record to address the issue?

This error is happening because I changed the name of the triChangeSpace form to cstChangeSpace since I needed to customize the form. If I keep my changes in place, I can rename the form to triChangeSpace and this message does not appear. The message also did not prevent me from being able to submit the request. The form name change also prevented me from selecting the Service Request type in the form, which I think is why the message is displayed in the first place…

As a side note, with the 3.5.1 introduction of object labels and revisions, you’re not required in 3.5.1 or later to use the classic “cst” naming convention any more. To others interested, here are the new naming convention best practices.

[Admin: This post is related to the 06.10.16 post about finding information on object labels and revisions.]

Continue reading

IV93263: Orphaned table T_TR_SU_QUE_RES_TR_SU_QUE


I have a table that does not seem to match the normal naming convention. We also noted that the table has no linkages to IBS_SPEC.

Can you confirm if it is part of the current TRIRIGA product? Perhaps it is left over from some old function. The table is T_TR_SU_QUE_RES_TR_SU_QUE and may be left over from some type of questionnaire. The content includes things like the following: “Did you like the move?” We have been upgrading since version 8. We are currently on TRIRIGA 3.5.1.3 and 10.3.0.

Continue reading

What is the downside of renaming TRIRIGA objects?


Mark Johnson: I am a big proponent of using a Naming Convention while doing development in a TRIRIGA environment. In fact, I have created the TRIRIGA Dash Notation naming convention, which I consider to be a superior naming convention. However, there is a downside to following a naming convention that I want to expose. Please do not mistake the following as a reason to not use a naming convention, but rather a call to recognize the downside and to be proactive in mitigating the risks.

The downside to using a naming convention is tied specifically to the instruction to rename customized out of the box objects. When forms or queries are renamed, there is a chance that some existing functionality is getting broken in the process. For forms, it is workflow tasks that potentially get broken by the rename. For queries, it is extend formula fields that potentially get broken by the rename…

Being aware of the ramifications of renaming forms and queries allows for the fixing of the issues created by the rename immediately, rather than waiting for it to pop up later. In software development, the sooner a bug is identified and fixed, the cheaper it is to fix. So be aware and be proactive in your TRIRIGA development, and whenever a form or query must be renamed, be sure to check for the impact and fix any bugs introduced immediately.

[Admin: This post is related to the 06.10.16 post about object labels and revisions, and the 05.17.16 post about avoiding the renaming of objects with object labels.]

Continue reading