What is the best way to handle calculated fields that need to reference the Current Date or System Date? For example, I have a number field in the Building BO called Building Age. To calculate the Building Age, I had to create another field called “cstCurrentDateDA” to store the current date the Building record was created.
From there, I take the Current Date minus the In Service Date of the building. However, let’s say I wanted the Building Age field to get updated daily. In my current design, I would have to probably create an asynchronous workflow to update the “cstCurrentDateDA” field and then trigger a Save action to get the extended formula against the Building Age field to fire.
Is there a better approach to dealing with field variables that rely on the Current Date or System Date? Instead of creating a custom field to store the Current Date to act as a constant factor?
[Admin: To see other related posts, use the Date tag.]
What is the “Integration” check box for in the workflow Start task?
Assuming you are referring to the Start task of an asynchronous workflow, when this property is selected, the workflow is used to migrate data from staging tables in IBM TRIRIGA records. This type of workflow is used extensively in IBM TRIRIGA DataConnect.
Check out this IBM Knowledge Center topic about DataConnect that describes the “Integration” check box: Workflow task settings.
[Admin: The same question is also posted in the main Application Platform forum. To see other related posts, use the Staging tag or DataConnect tag.]
We are scheduling an event with the current time, and associating it to one of the template records. In the same module, we have created a asynchronous workflow at the SCHEVENTSTART event. But once the event starts, the asynchronous workflow is not being triggered. Does anyone have any advice about this?
[Admin: To see other related posts, use the Events tag.]
When using a query and applying filters to classification or business object type fields, there are instances in which the data may not filter as expected. This can happen when the referenced classification or business object records are renamed, and the query is filtering on those name values. To summarize the scenario:
- (1) A user creates a record that contains a classification field, and populates that classification field with a value.
- (2) Another user changes the name of the classification record, which was used to populate the field in #1.
- (3) A user then runs a query that contains the field referenced in #1, and tries to filter values…
In order for filters to take effect for the most current value of a classification or business object type record when changed, records referencing those values in their fields must be updated. One approach to doing this is writing a simple workflow that updates the referenced data:
- Start Task: Workflow triggers on the classification object.
- Task 1: Gets the associated referenced object.
- Task 2: Clears the classification value.
- Task 3: Maps the classification field as the “Source” to the target field.
Note: For every object that the classification field references, the 3 tasks must be repeated. The workflow should only be triggered as an asynchronous process, since the workflow processing time will vary with how many records need to be updated.
[Admin: This post is related to the 06.08.17 post about SQL data not matching the viewed application data, and the 01.04.17 post about filters failing when using changed classification values. To see other related posts, use the Filter tag.]
We would like to keep track of the associations (Warranty For/Has Warranty) made and broken between any triWarranty and any triBuildingEquipment. The solution should provide information regarding the user making it change, the contract and asset concerned, the association name, and the new status (“Broken” or “Linked”).
We know that the check box “Audit All Data” in the business object properties already keeps track of the associations. By the way, is it the only one property doing that? But we don’t really want to do an audit of all the data of triBuildingEquipment. Some fields are already auditable and we don’t want to audit the others.
In short, what would be the best practice to get a permanent and precise tracking of associations made between two objects? I am wondering if the triLog module would do the trick, either by creating a new cstAssociationLog business object, or by using an existing one and having an asynchronous workflow creating the log.
Actually, a follow-up question would be: How can we use the triLog module to implement a new logging system? I am pretty sure the question is not new, so maybe a redirection toward a chosen part of the documentation that I might have missed would help.
[Admin: This post is related to the 08.24.16 post about tracking when and who created an association.]
A maximum threads error followed by a server crash can happen in some cases, where there is a large number of asynchronous workflows having trigger tasks in the WF_EVENT queue. This problem was first seen with Reserve, with the server crashing soon after starting due to triStartWakeUp and triEndWakeUp tasks. The problem described in this APAR is not specific to Reserve.
[Admin: This post is related to the 07.29.16 post about the recommended maximum threads, and the 08.24.15 post about using a thread “lock” in the workflow.]
In general, record transitions from “Draft” to “Active” either invoke a Close via the transition, or via a workflow invoked during the called action in TRIRIGA. This allows for a page refresh, and is important in the context of the Status value displayed on the record.
In some cases, it is possible to encounter a race condition where the page refresh/reload action is caught behind asynchronous and synchronous processes. An example is in the Work Task record. If the transition action does NOT invoke a Close action, the record status can display “Review In Progress” after activation. This is described in the attached graphic…
As a rule, it is more process-safe to call Close when there are asynchronous workflows operating against the workflow at the time of a state transition, as shown on the right-hand side of this graphic. Data is not displayed as permanent till a Close or Permanent Save is called.