CAD Integrator Logging Locations

To elimate confusion about where to locate CI logging, I want to explain where to find the logs.

The CI logs are located on the local end users machine. Typically you will find the logs in the ProgramData directory (for ex: \\programdata\IBM\CAD Integrator\Log.) Here you will find not only the CI.log, but also the httpwire.log, performance.log, and the CI.out log as well. All these are important troubleshooting and debugging resources used in the event there is a problem with CI. If you do not know how to turn these logs on, you can find instructions here: CAD Logging. 

Its important to mention that although these logs capture valuable information, you can also capture information regarding CI in the server.log file on the application or platform server. For this you will navigate the admin console to Platform Logging. From there you can add a manual category for " com.tririga.ci " and apply this. What will happen is now the server will put debug logging information about CAD Integrator in the server.log file. You can then replicate the issue and retrieve the server.log file from the Error Logs selection in the admin console. Just make sure to pick up the log with no datestamp.

Taken from https://www.ibm.com/developerworks/community/blogs/8eeee156-f1f3-45ec-970c-53b17ccb452a/entry/cad_integrator_logging_locations?lang=en

BIRT Report Parameters - Using Hard Coded SQL Statements

Today I would like to talk about BIRT reports and, in particular, report parameters that are hard coded select statements in the report design file. The following will be especially important for those people running their application in SQL Server.

The latest release of TRIRIGA includes several security reports that contain hard coded SQL select statements. Unfortunately, the select statements apparently cause a problem for those clients using SQL Server. The report is supposed to display the list of security groups. It does this via a simple select statement that gets the group name from the t_group table and looks like this:

SELECT name1 FROM t_group WHERE name1 <> 'Admin Group';

If you take that SQL statement and run it in the Admin Console->Database Query Tool you will see the expected results. When run from the context of a BIRT report, however, SQL Server does not appear to handle the select statement properly and you end up with a parameter list with no values. To correct the problem, you need to uppercase the entire SQL statement with the exception of the value in quotes. So the altered SQL statement will appear as follows:

SELECT NAME1 FROM T_GROUP WHERE NAME1 <> 'Admin Group';

In general, SQL Server BIRT report writers, be aware that if you decide to hard code a select statement such as this to provide the values for a prompt and you do NOT see anything in the list box for parameter selection, check the select statement that you used and make sure you uppercase all of the select statement that references either a database object or are reserved SQL keywords. Obviously, in the case of text searches as the one noted here, the case must match the expected value in the database.

You may now be asking yourself, how do I go about changing that in our BIRT reports? It is relatively easy and the following are instructions on how to do this within the report designer tool. I am assuming the report writers are familiar with the report design lifecycle. These instructions were written with the report mentioned above, so you will need to generalize as appropriate.

1 - In the report designer, expand the Data Sets section to reveal the SecurityGroups and SecurityPermissions datasets.
2 - Expand the SecurityGroups dataset to reveal the NAME1 object.
3 - Click on the Advanced vertical tab in the Property Editor.
4 - Scroll down to find the Query property. It will look as if the Value is set to "SELECT name1".
5 - Click on the Value and you should see this SQL:

SELECT name1
FROM t_group
WHERE name1 <> 'Admin Group'

6 - Everything except 'Admin Group' should be in uppercase in order for SQL to process the query correctly in SQL Server environments.

Taken from https://www.ibm.com/developerworks/community/blogs/8eeee156-f1f3-45ec-970c-53b17ccb452a/entry/birt_report_parameters_using_hard_coded_sql_statements?lang=en

Missing AutoCAD or MicroStation exception installing the CAD Integrator

Question

When installing the CAD integrator (IC) you sometimes receive an error message to say AutoCAD or MicroStation are not installed even though you know they are installed.

Why?

A check list before calling up support for assistance.

Exception on install:

""A supported version of AutoCAD or MicroStation must be installed on your computer before installing IBM TRIRIGA CAD Integrator/Publisher. Please close this installer, install the required software, then reinstall IBM TRIRIGA CAD Integrator/Publisher.""

Cause

The error is generic and can have other causes besides AutoCAD not being installed.

Answer

Check the following.

1. Ensure AutoCAD is installed.
2. Run install.bat (ie Run as administrator).

So right mouse click on the InstallCI.exe and run as administrator.

3. Make sure you have applied the SP2 to AutoCAD 2013.

4. Confirm what OS you are using, win2008 will not work.

5. Make sure using Java supported in TRIRIGA Matrix has been installed

TRIRIGA Support Matrix:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20TRIRIGA1/page/IBM%20TRIRIGA%20CAD%20Integrator%20Publisher

6. Make sure using (64 bit) Java with 64 bit AutoCAD and vice versa for (32 bit) releases.

This is most common cause where the Java installed is not correct in terms of 32 or 64 bit..

So if installing 32 bit AutoCAD install 32 bit Java and the same for 64 bit installations use 64 bit Java.

------------------------------------------------------------------------------------------------------------------------
If this still fails to resolve the install exception then send this information to support.
------------------------------------------------------------------------------------------------------------------------

1. What version of AutoCAD are you using?

2. What version of TRIRIGA are you using both platform/application releases?

3. What database, application server and OS is TRIRIGA deployed to?

4. What is the OS of the AutoCAD client?

5. Provide the ciinstall.properties file.

Located: <installdir>\CI-12\ciinstall.properties

Example:
C:\Program Files\IBM\TRIRIGA\CI-12\ciinstall.properties

Taken from http://www-01.ibm.com/support/docview.wss?uid=swg21660344

How to turn on full logging for CI

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM+TRIRIGA1/page/Turn+on+full+logging+in+CI

SQL to find all related items to a TRIRIGA Form

SELECT m.module_name Module, w.bo_type_name BO, w.wf_name Workflow,
 w.wf_template_version, wtn.Name TaskType,
 e.FORMULA Formula, ep.PARAM_STR Parameter
FROM TASK t, WF_TEMPLATE w, wf_lookup wl, IBS_MODULE m,
 expression e, expression_param ep, wf_task_name wtn
WHERE (ep.param_str LIKE '%fieldName=''triFormNameSY''%')
and e.formula like '%RealEstateLease%'
AND ep.FORMULA_ID = t.MAP_ID
AND e.ID = t.MAP_ID
AND t.wf_template_id = w.wf_template_id
AND t.version = w.wf_template_version
and w.wf_template_id = wl.wf_template_id
and w.wf_template_version = wl.wf_template_version
AND w.status_id IN (10,20) -- (Published, Revision-In-Progress)
AND m.MODULE_ID = w.BO_CLASS_TYPE_ID
AND t.TASK_TYPE = wtn.TASK_TYPE
ORDER BY Module, BO, Workflow, TaskType;

Agent Startup in N-Tier Systems

This is a discussion on how to configure the different TRIRIGA Platform Agents to start-up on N-Tiered systems.
Most of the agents are single-instance, and do not allow multiple instances to be run on multiple servers. The exception to this are the two multi-instance agents: Workflow Agent, Reserve SMTP Agent and Data Import Agent. Problems can occur if single-instance agents are attempted to be run simultaneously. The Agent Manager across the servers will prevent single-instance agents from being started multiple types. 

The following outlines some different common n-tier server configurations.

Case 1 Two Servers: Application Server and Process Server

The first case we'll examine is where there is a Application Server, and a Process Server. The Application server is where the end users sign in to, and the Process Server is where the majority of agents are running. 

These are where the agents should be running:

Application Server: DataImportAgent, ReportQueueAgent
Process Server: CleanupAgent, DataConnectAgent, DataImportAgent, ExtendedFormulaAgent, FormulaRecalcAgent, IncomingMailAgent, ObjectMigrationAgent, ObjectPublishAgent, ReserveSMTPAgent, SchedulerAgent, WFAgent, WFFutureAgent, WFNotificationAgent 

Note, for Agents like the IncomingMailAgent or WFFutureAgent can be disabled if you don't have the license are not using those features. 

Case 2 Three Servers: Two Application Servers and a Process Server

This case the Application Server is split into two servers, with some sort of "stick session" load balancing. We only need to run the ReportQueueAgent on one of those servers, that is where the users will be redirected once the report has completed running in the background:

Application Server 1: DataImportAgent, ReportQueueAgent
Application Server 2: DataImportAgent
Process Server: CleanupAgent, DataConnectAgent, DataImportAgent, ExtendedFormulaAgent, FormulaRecalcAgent, IncomingMailAgent, ObjectMigrationAgent, ObjectPublishAgent, ReserveSMTPAgent, SchedulerAgent, WFAgent, WFFutureAgent, WFNotificationAgent
Case 3 Four Servers: Two Application and Two Process Servers

When splitting up the process server, you could consider one process server the main Workflow server, and the other the main Extended Formula Agent server. While the Workflow Agent can run on both process servers, less threads should be allocated two the server running the Extended Queue agent. This is to allow more resources to be available to the Extended Queue Agent. For example, Process Server 1 can start out with 10 WF Agent Threads, while Process Server 2 could start with 5. When deciding on the other agents, you can spread the load across the two process servers. A tuning exercise should be done to best determine the number of threads is optimal for each server. 

Application Server 1: DataImportAgent, ReportQueueAgent
Application Server 2: DataImportAgent
Process Server 1: CleanupAgent, DataImportAgent, FormulaRecalcAgent, IncomingMailAgent, ReserveSMTPAgent, WFAgent, WFFutureAgent, WFNotificationAgent
Process Server 2: DataConnectAgent, DataImportAgent, ExtendedFormulaAgent, FormulaRecalcAgent, ObjectMigrationAgent, ObjectPublishAgent, SchedulerAgent, WFAgent

Taken from https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014916192

IBM TRIRIGA Application Platform Installation Information

Before you install IBM TRIRIGA Application Platform

http://www-01.ibm.com/support/knowledgecenter/?lang=en#!/SSHEB3_3.4.0/com.ibm.tap.doc_3.4.0/ins_install/c_ist_system_requirements.html

Installing IBM TRIRIGA Application Platform

http://www-01.ibm.com/support/knowledgecenter/?lang=en#!/SSHEB3_3.4.0/com.ibm.tap.doc_3.4.0/ins_overview/t_ctr_install_ibm_tap.html

Verification Checklist

http://www-01.ibm.com/support/knowledgecenter/?lang=en#!/SSHEB3_3.4.0/com.ibm.tap.doc_3.4.0/ins_install/c_ist_verification_checklist.html

Configuring the Platform

http://www-01.ibm.com/support/knowledgecenter/?lang=en#!/SSHEB3_3.4.0/com.ibm.tap.doc_3.4.0/ins_configure/t_ctr_cfg_configure_platform.html

IBM TRIRIGA Application Platform Performance Wiki

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20TRIRIGA1/page/Performance

System Sizing

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20TRIRIGA1/page/System%20Sizing

Capacity Planning and Performance Overview

As with any web based platform, the application server and database capacity needed to deploy a system built using IBM TRIRIGA Application Platform largely depends on the number of anticipated users and user requests.

The limits of what is needed are determined by how users are expected to use the system. At a minimum, enough server capacity to satisfy the average load during a work day will be required, with response times that are acceptable to the user base. If possible, strive to satisfy the volume of requests anticipated during peak intervals of high user activity. Hardware resources such as CPU, memory, I/O capacity, and network bandwidth are key to reducing response times. Unless you install IBM TRIRIGA on a server or group of servers that can handle a large number of transactions, users are probably going to experience slow response times.

Adding more servers and database capacity can sometimes improve IBM TRIRIGA's performance, but that is not always the case. The application usage and system configuration can play a significant role in the balance of system performance. Please see the IBM TRIRIGA Application Platform Best Practices for System Performance white paper for more information on tuning the environment.

Sizing & Estimation Methodology

Estimating anything can be a complex and error-prone process. That’s why it's called estimation, rather than a calculation.

There are two primary approaches to sizing a TRIRIGA implementation:

• Size By Example Based
• Proof of Concept Based

Size-By-Example Based

A size-by-example (SBE) approach requires a set of known samples to use as data points along the range of system size. The more examples available for SBE, the more accurate the intended implementation will be.

Targeted SBE sizing solutions for prospective TRIRIGA customers are provided in this wiki. These targeted solutions were compiled from our internal deployments, performance benchmarks, and customer's external deployments.

Proof of Concept Based

A proof of concept (POC), or pilot based approach, offers the most accurate sizing data of all approaches.

POC Steps:

• Test your implementation design
• Test your chosen hardware platform
• Simulate projected load
• Validate design assumptions
• Validate IBM TRIRIGA
• Provide iterative feedback for your implementation team
• Adjust or validate the implementation decisions made prior to the POC

There is, however, two downsides to a POC based approach, namely time and money. Running a POC requires the customer to have manpower, hardware, and the time available to implement the solution, validate the solution, iterate changes, re-test, and finally analyze the POC findings. A POC is always the best and recommended approach for any sizing exercise. It delivers results that are accurate for the unique implementation of the specific customer that are as close to deploying the real live solution as possible, without the capital outlay on hardware and project resources.

Topic Categories

·         Hardware Requirements

·         Software Requirements

·         Hardware Configuration

·         Development Environment

·         Basic (Small) Environment

·         Typical (Medium) Environment

·         Advanced (Large) Environment – Coming Soon

Other Resources

·         IBM TRIRIGA Release Notes

·         IBM TRIRIGA Application Platform Compatibility Matrix

·         IBM TRIRIGA Application Platform Version 3 Installation and Implementation Guide

·         IBM TRIRIGA Application Platform Version 3.3 Best Practices for System Performance

---

Servers

The IBM® TRIRIGA® Application Platform uses many different types of servers. The word "server" is often used to mean a physical piece of equipment, but it can also represent a logical separation that is based on function. Each of these logical servers can be collocated on physical servers, or separated so that each logical tier is installed on their own physical server.

Alternatively, each of these logical tiers can be installed on one or more virtual servers. In turn, these virtual servers can be on a physical server, or a cluster of physical servers in a virtual server cluster.

The following logical function-based servers are used in the IBM TRIRIGA Application Platform:

Web server Receives HTTP requests for web content. Also referred to as a front-end server.

Application server Carries out the user business logic with JBoss Application Server, Red Hat JBoss Enterprise Application Platform, WebLogic Server, or WebSphere® Application Server.

Process server Carries out the background processing and analytics with Red Hat JBoss Enterprise Application Platform, WebLogic Server, or WebSphere Application Server.

Tools server Carries out the reporting. Holds other third-party tools such as Brava! Enterprise Viewer for IBM TRIRIGA.

Database server Holds the relational database and supported database management system such as Oracle Database or Microsoft SQL Server.

Web server

The web server is the tier with which each user web browser communicates. Examples of web servers include IBM HTTP Server, Microsoft Internet Information Services (IIS), and Apache HTTP Server. The web server handles HTTP requests only and does not run business logic. The IBM TRIRIGA Application Platform also supports Secure Sockets Layer (SSL) by using HTTPS. Typically, HTTP uses port 80 (non-secure connection) and 443 (secure connection), but it can be configured to use other ports. Each time a user requests a JavaServer Page (JSP), the web server passes the request to the application server for processing. The web server is a physical manifestation of the web tier.

Application server

The application server is a Java virtual machine (JVM) with an instance of the runtime application. This server runs most of the business logic. Application server processes are CPU-intensive and require a great deal of memory. The application tier consists of JavaServer Pages (JSP) and Java classes. The Java™ 2 Platform, Enterprise Edition (J2EE) application server provides a JSP container, a database connection pool, and transaction management services. The application server is a physical manifestation of the application (middleware) tier.

Process server

The process server is a JVM with an instance of the runtime application that is set up as a dedicated processing or analytics engine. This server is configured almost exactly like an application server, but no users sign on to this server. It handles all workflow requests that are queued from users or by the IBM TRIRIGA software. The process server is a physical manifestation of the application (middleware) tier.

Tools server

The tools server houses the two major third-party extensions from IBM TRIRIGA. This server can run the optional Brava! Enterprise Viewer for IBM TRIRIGA or optional Business Intelligence and Reporting Tools (BIRT) process server or both. You can designate a IBM TRIRIGA application server as a BIRT process server. If you choose to run both BIRT and IBM TRIRIGA on the same server, expect BIRT report handling operations to increase the load on the server. BIRT is run in the same JVM as IBM TRIRIGA in all cases.

Brava is a web-based client-server package that provides view, markup, and collaboration functions. Viewers use a thin client to display documents that are rendered by the server. This process eliminates many compatibility issues and lowers the number of software applications that are needed by users.

Database server

The database server runs the database process. The database is where data is stored. The major database servers use Structured Query Language (SQL) to store and retrieve data. The Oracle Database server and Microsoft SQL Server use SQL. But each server is a different database engine and each has its own extended SQL for competitive differentiation. The application tier communicates with the database tier by using JDBC connection pools. The database server is a physical manifestation of the database tier.