Hey everyone, I wasn't sure where to post my question, but this seems like the right ballpark!
I'm working with a Declare Expression where I've run into an odd scenario that I'm not sure how to configure. I currently have my Declare Expression's Change Tracking set to Whenever Inputs Change along with an additional dependency dictating whether the work object is dirty or not. I'm attempting to tell the Declare Expression to simply exit (or even set its associated property to itself) when the IsDirty property is set to false. My initial thought was to just set the DE's property to itself, but an error is thrown saying I'm declaring a circular reference.
Does anyone know if there's a way to have a Declare Expression exit under certain circumstances? Thanks!
***Updated by moderator: Lochan to close post*** This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
It seems that if you define the declare-expression to evaluate a decision tree, and that decision tree sets its "DecisionTreeStatus" to the value "NotFound", then the actual setting of the target property will be skipped.
I determnined this by making a declare-expression that used the "evaluate decision tree" choice to set the target property .pyLabel, and then I launched the coffee cup icon. Here's the part of that resultant java showing the actual setting of the target property.
Hi. I don't know of any way to do what you're trying to do with a Declare Expression. I might take a step back and look at your business requirement. Is there a different way to get the same result? If you don't want to recalculate unless the dirty flag is clear, then you probably don't want to do it until you pass validation and are ready to move forward in the flow. Could this be done as part of the post processing on your flow action? If it needs to be done as a declarative, but only on a "clean" item, perhaps in an activity called by a declare trigger or something would meet your needs.
I was hoping to accomplish this in a different way, but I'm having issues finding a better solution. Let me explain, maybe you can give me your two cents...
I have a work object that has a Cost, Currency, and Date associated with it. With this information, we're calculating what the cost of the work object is in the user's home currency (where the home cost is called Final Cost and home currency is FinalCurrency). The reason behind using a declare expression is that when a user generates a work object and fills out these fields, we can show the work object with the user's Final Currency with Final Cost.
There's no issue there, logically it works fine in our application, the issue I'm having is with performance. There's a Report Definition that pulls back a list of work objects with the Cost, Currency, Date, Final Cost, and Final Currency properties. What's happening is that every time the Report Def runs, the Declare Expression fires that calculates Final Cost (which includes a web service call, it's heavy to keep running over and over). My solution to this was to have our Declare Expression not run when the Final Currency of the work object was already in your home currency.
Do you have suggestions other than my approach?
Posted: 7 years ago
Posted: 24 Feb 2015 15:52 EST
Eric Osman (ericosman_GCS)
Senior Software Solutions Engineer
>>> My solution to this was to have our Declare Expression not run when the Final Currency of the work object was already in your home currency.
You may want to review the choices offered on the “change tracking” tab of the declare-expression. In particular, you can choose whether the target property gets updated only when some piece of code tries to read that target property value, or whether it gets updated when one of its dependent properties get updated.
In general, if the target property value is read a lot more often than any of its dependent properties get updated, then its more efficient to update the target when dependent properties get updated.
If the target property value is read a lot less often than any of its dependent propreties get updated, then its more efficient to update the target only when it is read.
Posted: 7 years ago
Posted: 24 Feb 2015 16:06 EST
Mike Townsend (MikeTownsend_GCS)
Director, Technical Support, Customer Service
If I follow, the Declare Expression is fine for your work objects. That's where you do your calculations and life is good. The problem is that you have a report definition that pulls that data out of the database and it's firing for every row, because the inputs have changed from null to something. Under this circumstance, you don't want it to fire. Can your report definition pull the values into properties that aren't associated with the declarative (Cost_RptDef, Currency_RptDef, etc.)? The trick here is figuring out how to do the calculation when you want to. If you create a wrapper for the call to the report definition, then you can iterate through the results and if the FinalCurrency and Currency_RptDef are not equal, run the calculation, before ultimately displaying your data, that should only make your costly web service calls when you absolutely need them.
Hey Mike. I ended up going through and implementing it this way -- it seems the most logically straight forward.
Originally this report def was populating a data page that populates a a page list property. I've now changed the data page to populate via an activity which runs a modified version of the report def, pulling back fields that should contain a copy of the property with the declare expression attached to it. In the case where I need a newly updated value, I can reference the property which has the declare expression and get newly updated data only when I want.
As a note for anyone else who uses this, I did run into a hiccup when moving data from the report def list to the data page. When copying the report def list (mine was called ItemList) to the data page (D_ReportExpenses), you need to do a Page-Copy from ItemList directly to D_ReportExpenses. There were some extra data fields pulled back from the report def that, when missing, caused some issue for me down the line.