A navigation item whose target is set to “External URL” and whose URL links directly to a folder no longer works. An error such as the following might occur: “An error occurred, please contact your system administrator: [MID-4077624314].”
The Java applet that uploaded documents based on the navigation item target in earlier TRIRIGA versions is deprecated due to security concerns. Most browsers no longer support Java applets. The applet upload function is replaced with an HTML5 upload function.
As a result of these changes, “External URL” navigation items in earlier TRIRIGA versions that successfully uploaded documents via portals to upload documents to a folder might no longer work. The Document Upload widget was redesigned to be used only in the context of either Document Manager or a record, not a portal. Use Document Manager directly to upload documents.
[Admin: This post is related to the 04.07.17 post about “External URL” navigation items that may no longer work, and the 07.10.15 post and 04.10.15 post about the document upload enhancement. To see other related posts, use the Document Manager tag.]
When you try to run one of TRIRIGA’s Application Platform or CAD Integrator installers, most often on a Windows 10 or similar machine, the following InstallAnywhere-based “LaunchAnywhere” error may occur:
“Windows error 2 occured while loading the Java VM.”
This is an issue, not with running the TRIRIGA installers on a Windows 10 machines, but with Flexera InstallAnywhere found within TRIRIGA installers having difficulty parsing the version as it is listed in Java 8 Update 60 and higher. The specific problem being encountered is described here.
Determine if the installer that is running is using Java 8. If so, to determine if the version of Java 8 you are running is update 60 or higher, perform the following… If the version of Java 8 you are running is update 60 or higher, run the TRIRIGA platform or CAD Integrator/Publisher installer using the following command…
[Admin: To see other related posts, use the InstallAnywhere tag.]
You can configure TRIRIGA to use Tivoli Directory Integrator as its ETL runtime engine to run ETLJobItems from within TRIRIGA.
Before you begin
Install Tivoli Directory Integrator, if not already installed, on all the TRIRIGA systems that could run a TDI ETL Job Item. During the TDI install:
- Make note of the installation directory you enter on the Destination panel. You will enter this value later in TRIRIGAWEB.properties.
- Select either installation type. TRIRIGA requires only the TDI Server component.
- When prompted for the location of the Solution Directory, you can select any option. TRIRIGA specifies its own solution directory at runtime. However selecting the option “Use Install Directory” may simplify troubleshooting.
- Make note of the value you enter in the Server Port field on the Server Port Values Panel. You will enter this value later in TRIRIGAWEB.properties.
- Clear the “Start the Configuration Editor” check box on the Install Complete panel.
- Note: This step is very important for TDI/TRIRIGA integration to work. After you have installed Tivoli Directory Integrator, update it with the recommended fix packs (per TRIRIGA support matrix). TDI must be at least at FP04 (126.96.36.199) or it will not automatically start the TririgiaETLDispatch.xml assembly line which will result in ETL job items failing to run successfully.
- Edit TRIRIGAWEB.properties file to enable TRIRIGA to manage TDI server. Set the following properties…
- Install a JDBC driver library so that Tivoli Directory Integrator can use it to access TRIRIGA database…
- Edit TDI global.properties file to allow TRIRIGA to check and stop the TDI server from localhost without requiring authentication and authorization certificates. Set the api.remote.ssl.on property to false to tell TDI to trust requests from localhost…
- Start Tivoli Directory Integrator Agent from TRIRIGA Admin Console and verify that it starts successfully…
[Admin: This post is related to the 08.03.16 post about installing, upgrading, or uninstalling TRIRIGA TDI, and the 05.01.16 post about documentation on developing TDI with TRIRIGA. To see other related posts, use the TDI tag.]
When I run the CAD Integrator (CI) 12.1.1 installer, I get the window: “No supported version of AutoCAD or MicroStation were found on your computer.” On the next screen, I am able to manually select AutoCAD 2013 and 2014, and the install completes normally. The CI menu does not appear in the menu bar, so I have to manually add it by using the menu load process and navigating to the TrgaAcad_en.cuix file. However, it doesn’t stay loaded and I have to reload it every time I open AutoCAD 2014.
Also, once loaded, none of the functions in the IBM TRIRIGA CI work. For example, I keep getting: “Unknown command “TRGA_PREFERENCES”. I tried to use the APPLOAD process to try and load, but I don’t know the name of the CAD Integrator ARX file. Regardless, the install doesn’t appear to work properly. I tried to uninstall and reinstall 4-5 times, rebooted, re-downloaded the install file, etc. The menu won’t stay loaded, and I need the name of the ARX file to try the APPLOAD.
Here are a few notes:
- Loading the menu does not load the plugin. If the plugin loads properly, then it will automatically load the menu if not loaded already.
- Since the plugin is not actually loaded, none of the commands will work, hence the unknown command.
- There is no ARX file. It’s a .NET assembly that requires netloading of the correct DLL.
- Question: Are you using a 32-bit JVM instead of 64-bit? This is a known issue. We have an installer check for this now, but I am not sure it’s in 188.8.131.52: Troubleshooting CAD Integrator V.12 – Resolving No CAD Types Found on installation
- Make sure you know that 184.108.40.206 does not support Java 8. That might be an issue.
- If that’s not the problem, it might be some sort of security issue where the installer does not have permission to read or write to the registry in order to install CI. You can try installing with Admin privileges. We also have a wiki about it: Troubleshooting – AutoCAD – Unknown command after CI Install
- The “No supported version…” message is there, so the installer cannot install anything. The fact that you can select AutoCAD just means it will deploy the necessary files, but will not actually install it. Refer to: Manually Loading CI using Netload
[Admin: This post is related to the 09.04.16 post about adding the menu in the menu bar. To see other related posts, use the Integrator tag.]
After performing a TRIRIGA platform upgrade, some of the floor plans are not visible in the forms. Why aren’t they visible?
The TRIRIGA server cache needs to be refreshed. In other words, you need to clear the caches and restart the server. Here are more-detailed steps to clear your TRIRIGA cache and log folder:
- Login to the Admin Console.
- Go to the “Cache Manager” managed object.
- Click on the “All Caches (Global)” link and then “Hierarchy Tree Data – with rebuild” link. The process might take some time.
- Go to the “Database Manager” managed object, and click on the “Reprocess published drawings” link. Give the process some time to finish. Go to the current server log, and look for a related entry saying that the reprocess published drawing actions are finished. You will find a message similar to the following:
“INFO [com.tririga.platform.graphics.vector.drawing.DrawingService](http-0.0.0.0-21001-7) Finished re-processing drawings”
- Logout of the Admin Console.
- Stop the TRIRIGA JVMs via the WebSphere Admin Console.
- Delete the logs in the <TRIRIGA install>/log folder that has server.log.
- Clear the WebSphere temporary cache folder.
- Restart the TRIRIGA JVMs via the WebSphere Admin Console.
[Admin: This post is related to the 07.15.16 post about floor plan graphics disappearing after an upgrade, and the 09.29.14 post about clearing the TRIRIGA application server cache area. To see other related posts, use the “floor plan” or “clear cache” search phrase.]
There may also be an issue where the menu does not load, unless you use the CUILOAD command directly to load the TrgaAcad_en.cuix directly from the install directory. Then, attempting to login results in a _TRGA_LOGIN Unknown command “TRGA_LOGIN” message. The cause of this issue is that the CAD Integrator/Publisher (CI) is not initializing correctly…
Assuming NETLOAD works, the main issue is that probably the CI installer does not have permission to update the registry. CI actually uses the JVM and the command line to update the registry, so on certain secure systems, it may not be allowed to update the registry as needed to tell AutoCAD to load CAD Integrator…
The main issue is a permission issue where the CI installer cannot update the Windows registry to enable automatic loading, which is outside the control of the CI installer. If the CI installer cannot update the registry, then see the workaround…
[Admin: To see other related posts, use the Integrator tag or AutoCAD tag.]
I am having an issue when creating Java classes (TririgaWS and TririgaWSPortType) from the Apache CXF WSDL2Java utility. I am using Apache CXF version 3.1.1. My TRIRIGA version is 3.5. The issue is that the CXF WSDL2Java tool is creating all Java services except the TririgaWS and TririgaWSPortType Java file.
I am generating the Java file via the command prompt:
> wsdl2java http://localhost:8001/ws/TririgaWS?wsdl
WSDLToJava Error: Parameter: content already exists for method delete but of type com.tririga.ws.dto.content.Content instead of com.tririga.ws.dto.content.Response. Use a JAXWS/JAXB binding customization to rename the parameter.
Try using the -autoNameResolution argument in your command. For example:
wsdl2java -autoNameResolution http://localhost:8001/ws/TririgaWS?wsdl
[Admin: The same question is also posted in the triDeveloper Google group.]
What are the concerns about stopping my database for maintenance and leaving IBM TRIRIGA JVMs (JBoss, WebLogic, WebSphere) up and running at this point? Will they be reconnecting automatically after my database is up and running again? I need to programmatically schedule database maintenance for my TRIRIGA system.
When the database is down, the application server (JBoss, WebLogic, WebSphere) will be receiving connection issues to the JDBC component and JVMs will stop responding after that. If the database comes up again, the application server will not reconnect the JVM automatically. The JVM needs to be restarted manually after that.
The best practice for database maintenance requiring database shutdown will always be to shutdown all applications and sessions connected to it BEFORE the database itself. It gives systems the time to close the ongoing transactions gracefully.
If you need to coordinate database maintenance and JVMs automatic restarts, you need to create a batch script to manage that. This is a customized script (not under IBM TRIRIGA support) that will be stopping the JVMs first, then starting the database maintenance itself (likely stopping the database first), then restarting the database and firing commands to restart the application server IBM TRIRIGA JVMs.
I am trying to develop a Java program to access a URL link like the following:
The problem is that I need to authenticate before doing so. Does anyone have an example on how I can do this with Java? I know it saves a cookie and this is how it makes the request, a saved cookie in the browser. Can I do that with Java?
Starting in TRIRIGA 3.5.1, a new BIRT engine was introduced with your TRIRIGA installation. This is BIRT engine version 4.6.0.
To customize or create new reports, as well to convert your old BIRT 4.3.1 reports, you need the same BIRT Designer version. This Designer runs on the Neon Eclipse platform and you can use your current Java 1.8 with it (in older designers, you needed a Java 1.6, 32-bit, to make it work). This new version is optimized for Mac (in older versions, a lot of manual steps were needed). Also, you can have it as an application now. For Windows, it remains a folder in the location of your choice.
Another often-raised topic is about “upgrading from 4.3.1 to 4.6.0”. The fact is you can have both installed in your machine. They are separate installations. The caveat here is that you cannot use the same workspace for 4.6.0, if you already have 4.3.1 installed, so you just need to rename the workspace used for the first time.
So let’s start with what you need…
[Admin: This post is related to the 08.19.16 post about failing to connect with 3.5.1, and the 08.18.16 post about getting an HTTP Error 500.]