Tom C

Users have created and tested the configuration file for an AutoREST JDBC connection in Jaspersoft Studio (JSS) but encountered difficulties deploying the configuration file to the AutoREST data source in JasperReports Server (JRS). The Progress driver (autorest.jar) JDBC connection can use a local file to preconfigure the schema translation to achieve high performance when large amounts of data are retrieved. This Progress JDBC configuration has the "Path to Config File" parameter to let users provide the full path to that configuration file on the local drive. The "Path to Config File" setting should be the full path to the configuration file for the data source from the local drive. This Progress JDBC configuration is implemented in JRS as-is therefore the repository resource reference "repo:" is not supported in this path settings. ============================================ 20240430-TTC-2263632

Below is a sample SQL query users can use to get all the report jobs listed by its associated report name, job id, next fire time, and job owner information from the JRS scheduler. The query is sorted by next fire time to help determine how the jobs are clustered for capacity planning. select TIMEZONE('EDT',TO_TIMESTAMP(q.next_fire_time/1000)) as next_job_run , TIMEZONE('EDT',TO_TIMESTAMP(q.prev_fire_time/1000)) as prev_job_run , TIMEZONE('EDT',TO_TIMESTAMP(q.start_time/1000)) as first_job_run , j.report_unit_uri as job_report_name , j.id as job_id , u.username as job_owner , t.tenantname as job_owner_org from qrtz_triggers q inner join jireportjob j on 'job_'||j.id = q.job_name left outer join jiuser u on j.owner = u.id left outer join jitenant t on t.id = u.tenantid order by 1 Sample query result: Note The query syntax is for PostgreSQL database. If users' JRS repository is using other DBs, users need to find equivalent DB functions for job name concatenation to couple the Quartz and JRS table integration, and to convert internally stored Epoch time in Quartz to a true timestamp in their respective database. With this query, users can create and deploy a report to the server and share the job information with non admin users who are not the report job owners. ================================================= 20240426-TTC-2256177

select f.uri as "Report Folder" , r.name as "Report Name" , r.label as "Report Reference" from jiresource r inner join jireportunit u on u.id = r.id inner join jiresourcefolder f on f.id = r.parent_folder order by 1 reportList.xlsx ========================================================= 20240426-TTC-2255650

Problem User has reported that they "have a report that runs well in the Jaspersoft Studio and the DEV report server, but it failed in the PROD report server. The Prod report server version is 7.5.0 while the dev server is 7.9.0". Analysis Jumping into conclusion, one might think the most plausible explanation of the problem is a report compatibility issue - perhaps the report template contains a design feature that only works in the new version of the JasperReports engine (JRL). Upon further review of the error message, however, the issue is not related to JRS/JRL versions used in user's production. Rather, it is caused by user's report data: net.sf.jasperreports.engine.fill.JRExpressionEvalException: Error evaluating expression for source text: $V{GroupGrandTotal}.equals(0.0) ? "0.00%" : new BigDecimal($V{GroupItemTotal}.floatValue()*100/($V{GroupGrandTotal} .floatValue())).setScale(2, BigDecimal.ROUND_HALF_UP)+"%" ............ Caused by: java.lang.NumberFormatException: Infinite or NaN This error indicates the GroupGrandTotal report variable contains zero which cannot be used as a denominator in a division operation. User had attempted to handle this situation by this ternary expression $V{GroupGrandTotal}.equals(0.0) ?... : ... However, the BigDecimal.equals() method takes scale into consideration thus it only works when the group tally is exactly 0.0, not 0, or 0.00 nor 0.000, etc. Solution User should use the BigDecimal.compareTo() method instead to handle BigDecimal zero value evaluation irrespective of the scale: ($V{GroupGrandTotal}==null||BigDecimal.ZERO.compareTo($V{GroupGrandTotal})==0)?... : ... After making the change, the user is able to run this report successfully in all environments. Note Since the comparable interface requires a class instance to operate, users should ensure the BigDecimal field contains non null value. The normal way of using a constant literal in the ternary expression will not provide the safety net to handle the null situation when compareTo() method is used. Therefore users need to cover the null condition in the expression to be "NullPointerException" safe. Reference java.math.BigDecimal BigDecimal compareTo() Function in Java Interface Comparable -------------------------------------------------------------------------- 20240425-TTC-2260030

Q: Our user has asked how they can identify whether the report is view based/domain based/topic based. A: A JRS report can be created in three ways: Query based report created in JSS using a data adapter; Domain based report created in JSS using a domain adapter; Ad hoc view report created in JRS from an ad hoc view. The ad hoc view in turn can be created from a domain, a query based report topic, or a domain based topic. But those resources are only relevant to the ad hoc view, not directly related to the report. To determine which three of the above data sources a JRS report unit is using, we need to look no further than the jireportunit table itself. The resourcetype column contains the class type which can help to identify the report data source: com.jaspersoft.jasperserver.api.metadata.jasperreports.domain.JdbcReportDataSource and com.jaspersoft.jasperserver.api.metadata.jasperreports.domain.JndiJdbcReportDataSource indicate this is a query based report using JDBC and JNDI data source , respectively; com.jaspersoft.ji.adhoc.AdhocDataView is for ad hoc view report; com.jaspersoft.commons.semantic.datasource.SemanticLayerDataSource identifies a domain based report. Here is the sample query to fulfill the request. select r.name as reportName , f.uri as reportFolder , rd.name as reportDataName , rd.resourcetype as reportDataType from jiresource r inner join jireportunit u on u.id = r.id inner join jiresourcefolder f on f.id = r.parent_folder inner join jiresource rd on rd.id = u.reportdatasource

Configuring Google Global Load Balancer (GLB) With Sticky SessionJasperReports Server (JRS) supports partial session replication but not full replication, the load balancer must be configured so that browser users are always connected to the same server during a continuous session. This requirement is referred to as "sticky or pinned sessions" (refer to https://community.jaspersoft.com/documentation/tibco-jasperreports-server-ultimate-guide/v790/session-management-and-failover). To fulfill this requirement, when using Google Global Load Balancer (GLB) to host multiple JRS instances, our users deploy a "ring hash" load balancing strategy. The ring hash approach is used for both “sticky sessions” with a cookie and for “session affinity” based on primarily the client IP address to send all requests from a given client to the same server node. The ChallengeHowever, with the ring hash load balancing strategy, our users had discovered based on their trial run, that all their 300 users' requests only hit one JRS node defeating the LB distribution functionality. There's an inherited tradeoff with ring hash which can be more challenging to evenly distribute workload because the hashing is involved with the distribution of keys or requests in the system. To support full session replication in order to lift the restriction on sticky session requirement and avoid use ring hash, JRS will have to go through a major architecture design change to make it possible. Recommendations to GLB System Admin - Ensure that the hash keys are well-distributed across the ring. If the keys used for hash mapping are not distributed uniformly across the ring, it can lead to hotspots where all requests are directed to the same node. - Verify that the hash function used is suitable for the specific use case. If the hash function has poor distribution properties, it can lead to an uneven distribution of keys and, consequently, uneven traffic to the server nodes. - Adding more nodes to the hash ring can help mitigate this issue. With only a few nodes, the distribution of keys is inherently less even. - Using a hash function with a low collision rate and handling collisions properly is important. Hash collisions occur when different keys or requests are mapped to the same position on the hash ring which can lead to uneven distribution. - Implement weighted distribution to account for data skew. If certain keys or requests are more common than others, this can lead to uneven distribution. - Explore the option to use L7 proxy for round robin load balancing. Reference Materials https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancers https://blog.getambassador.io/load-balancing-strategies-in-kubernetes-l4-round-robin-l7-round-robin-ring-hash-and-more-6a5b81595d6c#:~:text=the%20given%20service.-,Ring%20hash,client%20to%20the%20same%20Pod https://www.toptal.com/big-data/consistent-hashing ============================ TTC-20231017