How do you use Dynamic Workflow settings in Call Workflow task?

I am looking for some explanations for the “Dynamic Workflow” property settings in the Call Workflow task. When should I use it?

The Dynamic Workflow property and fields allows you to pull the workflow name to execute from a task > field, instead of the workflow name being hard-coded in the workflow. The field must contain the workflow name to execute.

Excerpt from the “Application Building” (3.5.3, PDF) user guide:

Dynamic Workflow: The values of this field are used to dynamically define the name of the workflow that this task will launch. For the “Task with Workflow Name” drop-down list, select the task record that contains the workflow name. For the “Workflow Name Field”, select the field on the task record that contains the workflow name. This record field must contain the workflow name that you want to launch.

[Admin: To see other related posts, use the Workflow tag or Workflow Builder tag.]

Advertisements

What is the purpose and impact of the “Localizable” field property?

I’m seeing issues within report results, where if the user profile language is in US English, the results are of one type, but if the user profile language is in German, it is showing some other data. The record while checked is the same for both cases. While opening and checking the record, the ID and name of the record varies from what it showed as a result in the report. While investigating, what we observed is that these fields are marked as “Localizable” in Data Modeler. What is the use and impact of the “Localizable” field property? Any suggestions?

Here is a PDF link to the 3.5.3 Globalization (Localization) user guide. Also, perhaps this technote on localized database storage will help provide some insight.

[Admin: The same question is also posted in the main Application Platform forum. To see other related posts, use the Localization tag or Language tag.]

How do you transform an unsupported date format?

We would like to upload a date in “dd.mm.yyyy” format. As long as TRIRIGA doesn’t support this format, what would be the best way to transform a string with “dd.mm.yyyy” to Epoch date, and then copy it to a Date field inside TRIRIGA? For example, advanced formula, custom task, etc.?

I think one of the possible ways is to leverage an ETL tool (e.g. Kettle Spoon) to transform data. See the Data Management (PDF) user guide.

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

How do you configure parameters in TRIRIGA notification content?

I’m a new TRIRIGA developer. I don’t know how the parameters are passed in the notification content. For example, for {1}, how do I pass the parameters to it? In addition, TRIRIGA develops too little material for learning and how to get useful information.

The template for the notification content record is in the Details section. To set the content, you need to use a record based on the triNotificationHelper BO in the triHelper module. There is an excellent write-up in the Application Building for the IBM TRIRIGA Application Platform 3 [PDF] user guide in the IBM Knowledge Center. Take a look at Chapter 12: Notifications.

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

How do you update a record with Data Integrator?

I’m trying to update a record using Data Integrator. But currently, I have no good results with this. The record is just added, not updated. I would appreciate it if you could show me an example of updating the value of an existing record for an employee’s email address below. I might not have understood the publish name, or the unique key of TRIRIGA.

• (1) triIdTX: 1000004: This is the system generated number at record creation. I assume it’s used as the unique key. (I am not sure if it is the publish name or not.)
• (2) triLastName: Aaaaaaaa: This is the value with the same value when creating a record.
• (3) triFirstName: Bbbbbbbb: This is the value with the same value when creating a record.
• (4) triEmailTX: xxxxx@yy.zz.com: It was not set when creating a record. And I want to set this value as an update value.

Also, let’s suppose that some values are already set to other fields of triPeople, but are not specified in Data Integrator.

You are correct that it’s adding a record because you’re not using the Publish Name. Take a look at the documentation in Application Building for the IBM TRIRIGA Application Platform 3: Data Management (3.4.x PDF p.35 | 3.5.2 PDF p.31). I confirmed the publish name in our latest release is the same as documented: Last Name + ‘, ‘ + First Name + ‘ – ‘ + ID.

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

IV94789: Set up data source before exporting data load spreadsheet

The TRIRIGA 3.5.2 “Application Building: Data Management” user guide does not indicate that the data source needs to be configured before attempting to export a Data Load spreadsheet.

The steps for “Creating a data load spreadsheet”, as listed in the 3.5.2 “Application Building: Data Management” user guide, do not indicate that before doing this, you need to set up the data source properly. In fact, there is no mention of the need to set up the data-load data source in the guide until the “Processing and loading sample data” section, which comes after the section on creating a spreadsheet.

In the “Creating a data load spreadsheet” section, the following should be inserted as Step 3:

• 3. Ensure the data source is correctly set up for each data load item:
  • a. Select the data load item.
  • b. Select the Integration Object field.
  • c. In the Data Source section of the integration object form, modify the credentials of the database if needed.
  • d. Select the Test DB Connection link to verify that you can successfully connect to the database.
  • e. Save and close the integration object form.

The old Step 3 becomes Step 4.

IV90171: Changing users in WF Agent requires server restart

If we add or remove users from the Workflow Agent settings on process servers (as per “best practices” to only have one “open” process server and others “restricted”), we have to restart all process servers for the change to take effect.

The 3.5.0 Administrator Console user guide [PDF] does not suggest that a restart is necessary and since this is the new “best practice”, it should be dynamic rather than require a system outage every time you make this change…