How do you export more than 1000 records with integration object?


We are currently on TRIRIGA 3.5.1.3. I have an integration object that uses a static query to export records to a flat file. It works great when I click on the Execute action on the integration object. It can export more than 27,000 records. However, I only want to export a subset of those records, so I am executing it from a custom task as described here.

If there are 1000 records or less to export, executing from a custom task runs as expected. But if there are 1001 records or more, the workflow throws a NullPointerException (NPE). How can I get it to export more than 1000 records?

[Admin: To see other related posts, use the Integration Object tag or Custom Task tag.]

Continue reading

Advertisements

How do you import CL fields that have more than 100 characters?


I encountered a bug with classification (CL) field types. I have a classification BO with the publish name comprised of (ID – Name). I have a certain number of records where the character length in the Name field is about 150 characters. So the full length of the publish name will be more than 100 characters.

  • Problem: I went to a form that references that classification via an associated CL field. After I selected the value, I noticed that the displayed value showed a truncated value that was less than 100 characters. However, when I went to the Association tab of that form, it had the correct association.
  • Second Problem: When I imported data via Data Integrator (DI), I made sure that the CL field had the full path which is more than 100 characters. DI gave no errors after import. I opened the record to verify the CL field populated, but the CL field was not updated and left null. I had to manually select the value in the CL field to associate it correctly.

Question: How do I import data with CL fields that have more than 100 characters?

I am not sure how to import data with CL fields that are more than 100 characters, but if you feel you have encountered some bugs, please submit a PMR.

[Admin: To see other related posts, use the Classifications tag or Character tag.]

Continue reading

How do you populate the request class drop-down in work task?


I’m having issues with request classes on work tasks. We created a project (including work location). But now, when we create a task from the project, very few of the values (including work location) are mapped onto the null work task. The drop-down that comes from the request class depends solely on this work location.

Also, the work location of the task gets its value from the project (as mapped). But now, when we try to get the drop-down for the request class based on work location, random values are shown. When I reselect the same work location, and then go back to the request class, I see the correct values. Any thoughts on this behavior? How do you get the request class list for the very first time without reselecting the work location in a work task that was created from the project?

[Admin: To see other related posts, use the Mapping tag or Work Tasks tag.]

Continue reading

Why are BIRT report parameters failing in TRIRIGA 3.5.2?


I’m seeing an issue with report parameters in BIRT. I’ve added a report parameter and bound it to a filter condition. The report runs perfectly in Eclipse. But when I uploaded the same to TRIRIGA, it’s giving me errors while the report is rendering, after entering the parameters. Surprisingly, null checks have been implemented using a script at the table level as well as on the filters, so that optional parameters are dealt with. Here’s the exception trace…

This may be related to a known issue resolved in APAR IV96587. Try the most recent fix pack and see if it resolves the issue.  If it does not, I would put in a PMR.

[Admin: This post is related to the 11.13.15 post and 07.03.15 post about having issues with BIRT report parameters. To see other related posts, use the BIRT tag.]

Continue reading

Why do queries that are expected to display data show nothing?


When running queries against records within the application, expected record results are not displayed. Why do queries that are expected to display data show nothing at all?

Within the application, we have a variety of different settings that can restrict a user’s access to record data. The user’s Security Group can restrict access to records at the module and BO level, but each use case is slightly different. 

Within every user-facing record, on the System tab, there are fields for System Organization, System Location and System Geography. These values operate in conjunction with similar fields on the Security Group and the User’s People record to allow and restrict access to records. 

The key is that as soon as the user is given a defined Organization, Location, and Geography, the fields on the System tab of their People record are populated. Once that happens, each record they create will be seeded with that information as well. So far, all is well and good, but those users who lack similar settings are now unable to see those newly created records, unless their System fields are the same as or located at a higher point in the hierarchy.

Another area to consider is the Security Group settings for Organization and Geography. If a user has no values set on their People record, the application can still restrict access by using the Security Group values. This can cause a problem as the Organization and Geography Security is defaulted to null in the as-shipped application. This essentially gives the security code no starting point for determining access and will not display records.

To recap, if the record data does not align with the data in the user’s People record, or the data in the user’s Security Group, the record will not be displayed. As mentioned, there are a couple of things to look for. As an Admin user, compare the user’s record data with the record that should be displayed, and correct any misaligned data. Also, in the Security Group, set the Organization and Geography to the root of each hierarchy by default. For additional details, please review the following TRIRIGA wiki article: Security Overview.

Continue reading

Why is the root classification set to the ~ (tilde) symbol?


In my current TRIRIGA 10.3.2 / 3.5.2.1 environment, I see that some of the classification fields have a root classification value set to ~ (tilde) symbol. This seems strange to me, because classification fields can’t be created with a blank value or any such symbol.

And when I migrate the BO with such fields in another TRIRIGA 10.5.2 / 3.5.2.1 environment, it’s automatically populating the classification value (e.g. Expenditure Type) in the root classification. Has anyone seen a scenario where the root classification is set to the ~ symbol?

[Admin: To see other related posts, use the Classifications tag.]

Continue reading