How to pass value from each iteration as a ruleinput value for an another object

a!localVariable(

local!array: rule!integration2,

a!forEach(items: rule!integration2, 

expression: 'type!{urn:com:appian:types:TEST}TEST_CDT'(

name: index(split(index(index(rule!integration1(input: fv!item)), 1), 2), "/), "name"),

email: index(split(index(index(rule!integration1(input: fv!item)), 1), 2), "/), "email")

)

I want to perform the calculations in one local variable and pass fv!items from each iteration in the expression to that local variable and then simple index the values and fill in the values in the CDT.

My idea is:

a!localVariable(

local!calculation: index(split(index(index(rule!integration1), 1), 2), "/), 1),

local!array: rule!integration2,

a!forEach(items: rule!integration2, 

expression: 'type!{urn:com:appian:types:TEST}TEST_CDT'(

name: index(local!calculation(intVal: fv!item), "name"),

email: index(local!calculation(intVal: fv!item), "email"),

)

)

But intVal is a rule input for integartion1 object. What is the most efficient way to achieve this.

  Discussion posts and replies are publicly visible

  • 0
    Certified Lead Developer

    Maybe my blog post gets you started: appian.rocks/.../

  • 0
    Certified Lead Developer
    index(split(index(index(rule!integration1(input: fv!item)), 1), 2), "/), "name"),

    Tangentially, this is a good example, merely for readability/sanity reasons, of why I insist (in my personal best practice edicts at least, and those of the dev teams i've run now and in the past) that when retrieving a named property, you use property(), and reserve index() for when you're actually retrieving an index (that is to say, the index within an array of a particular value).

    Also: why are you even bothering to declare local!array when you then proceed to not even reference it in your a!forEach() call?

    If it were me, I'd do the digestion of the initial integration result in more granular stages, to help with visibility/troubleshooting/sanity.  I'll take your word for it as to the index positions, and I assume you were trying to split on "/" even though your original code above is missing the close-quote if so.

    a!localVariable(
      /* first we run integration 2, since its results will be fed into integration 1. */
      local!array: rule!integration2,
      
      /* next, we build our array of the raw result of integration1, for each member of the integration 2 result.
         we can worry about the splitting and indexing next. */
      local!integration1result: a!forEach(
        items: local!array,
        expression: rule!integration1(input: fv!item)
      ),
      
      /* now, assuming integration 1 worked, we build a list of the cherrypicked / split items, splitting on "/" */
      local!extractedResult: a!forEach(
        items: local!integration1result,
        expression: split(index(index(fv!item, 1), 2), "/")
      ),
      
      /* finally, we pull the "name" and "email" properties out of the extracted results above 
         note: we use "property()" here to get properties, since we're not getting indexes. the difference is readability. */
      a!forEach(
        items: local!extractedResult,
        expression: type!TEST_CDT(
          name: property(fv!item, "name", null()),
          email: property(fv!item, "email", null())
        )
      )
    )

    (BTW: notice how much more readable the code is when properly using the "Insert --> Code" functionality they give us here?)

  • Hi Stefan,

    Thank you for sharing the article, it was really helpful. The Article talked about reduce function.

    In my scenario, we have an integration object "integration1" that have a rule input intVal, how can I modify reduce function according to this requirement. 

  • 0
    Certified Lead Developer
    in reply to sanjuktab2257

    I dislike the reduce() function personally (though it's sadly the only way to do some niche operations, outside of making recursive expression rules which is also ugly), but either way, i don't believe it applies to the use case you've described here if i'm reading your code correctly.

    Please see my separate reply below in which I've refactored your existing code to (hopefully) accomplish the same functionality but much higher readability.

  • 0
    Certified Lead Developer
    in reply to sanjuktab2257

    To be honest, I did not have a deeper look into your code as it is almost impossible to read, and also hard to understand what you want to achieve.

    The best way to get great answers here, is to spend a bit of time on making it easy for us. I wrote blog posts and recorded podcast episodes on why this is important and how to do it.