We have quite a lot of rows in the extended formula queue that started to back up since Aug 29. At one point, we had over 900K in the queue and the process server is processing it pretty slowly. As of Sep 8, the system is still processing the queue. We are adding daily on average over 125K rows to the EF_QUEUE table.
We tried starting and stopping the Extended Formula Agent and Formula Recalc Agent and tried rebooting the process servers. We swapped the agents to run on different servers. We also ran the segment shrink on the EF_QUEUE table and gathered statistics. It is still extremely slow. We still have over 500K in the queue.
In parallel, we did open the platform logging on the extended formula activity and cache building, and we are working to identify the processes that can be fixed to reduce the multiple calls to the Extended Formula Agent queue. Do you have any recommendations to speed up the process to clear the extended formula queue?
Review the following two APARs. They may need to be applied to your environment to address this issue: (1) Platform: APAR IV87030. (2) Application: APAR IV87104.
[Admin: This post is related to the 07.28.16 post and 05.04.16 post about the Extended Formula (EF) Agent not processing and backing up the queue. To see other related posts, use the Extended Formula tag.]
Using any reservation form, and the “All Day” flag, reservations are generated. Then reopen the reservation which displays an “End Date” of year 5168… We’ve repeated this on a base product configuration and multiple browsers.
The following application fix was applied to resolve the issue. In Workflow Builder, open the workflow “triReservationManager – Synchronous – OnChange – All Day”. This workflow is located in the triReservation module and triReservationManager BO. Open the “Round” Modify task. Select the “Edit Map” link and scroll down to the triDurationDU field. Select the formula picker. The formula “86400000 * div(END-START, 86400000)” needs to change to “END-START”. Click OK in the formula picker, and on the map to save changes. Publish the workflow.
As I’ve understood it, both the integration object and DataConnect allow you to import localized data (except business key fields, I think). In addition, we have another option to use the Globalization Manager to import traditional data. I found it’s pretty cool. We will only deal with the localized data, with less impact for the non-localized data. Before going forward with an option, I’d like to know what’s the best option for you guys?
Importing by using the Globalization Manager updates the L_ tables directly. If your data does not include localized values that need to be concatenated, for example in a formula, the Globalization Manager import is your best option.
However, if your data includes localized values that need to be concatenated through a formula, or if your data needs to be processed by workflow before it is added to the TRIRIGA tables, then you should use either the integration object or DataConnect.
[Admin: This post is related to the 03.02.16 post about best practices for integration optimization.]
The Extended Formula (EF) Agent stopped processing the queue.
We need to limit the rows in EF_QUEUE (to reset AGENT_ID to -1) to only rows that have an existing valid AGENT_ID value during server startup. The AGENT_ID only gets populated with the ID of the EF Agent that picked it for processing. For whatever reason, the row may not have completed its process, but the server has already shutdown, thus having rows flagged with a non-existing EF Agent. In order for the EF Agent to continue processing these rows, their AGENT_ID values need to be reset to -1, so that the next time the agent awakens, they will be picked up for processing. Refactor the existing code, so it can be more JUnit tested, and is using SQL code, instead of a direct database connection.
Moving forward, the application server will now start up, even if there is a large number of rows in the Extended Formula queue.
Does TRIRIGA have a list of standard variables to use in an extended formula? I have a Number (NU) field that needs to take the [Current System Date – Construction Date]. However, my Construction Date is just a YYYY format. How would I go about doing this?
It looks like I found a different method to accomplish my goal. I created a cstCurrentDateDA field, then used an extended formula with the formula “CurrentTime()”. Then in my targeted field, I used an extended formula “Year(cstCurrentDateDA)-cstConstructionDateNU”. As such, I was able to return the correct difference. Any other methods are greatly appreciated for comparison purposes. Hopefully, my method will help someone else for future reference.
I have a requirement to concatenate the values of two text fields into a new field. For example, Field A has a value of “1000”, and the Field B has a value of “Hallway”. I would like to concatenate those two values into a Field C as “1000 Hallway”. Note the space in between “1000” and “Hallway”. I’m thinking I would have to create a workflow to concatenate upon OnChange. Any suggestions?
If your goal is to have the form refresh immediately when someone modifies either Field A or Field B, an OnChange workflow with a Modify task that has a string formula will solve your issue. Your formula would look like this:
- Formula Inputs: A = Field A, B = Field B
- Formula: A + ‘ ‘ + B
You can append static text by adding a string within quotes. This will give your final value with the space you want.
I want to do a custom sort of my status field in the work task for an OSLC query. I planned to implement this by adding an extended formula field, to calculate an index based on the status ID value, by which the sort order would represent what I want. But when I started this, I came across a problem: How do you compare the status with a value in the “if” condition of an extended formula?