E9.2 Manipulate Input using Groovy

[Stank1964]

I am just getting my feet wet with groovy and I am trying to figure out if I can use groovy to manipulate the input variable - which ultimately is really an orchestration input or orchestration variable. Let's say I want to pass a string into a very simple groovy custom request and have groovy make the string upper case. I don't want upper case new variable, I want the input variable to be upper case. Is that even possible the way Oracle built the groovy hook today?

 

[DaveWagoner]

So I have been noticing that if you have a variable as output that matches exactly the variable name from an earlier step, it does seem to "overwrite" the original variable even if you map back to the orch input var later on in the orch flow.

Give it a shot! Name the output var from your groovy the exact same as the orch input var name. Test mapping a later step to the orch input first, and later, the groovy output. Should see if orchestrator essentially overwrites the orch input var if the vars are named the same.

 

[nareen]

Hi Dave, how can we reset the Orch input variable after it completes a loop.

My scenario is for a specific Address book number I am calculating the grand total by looping through the grid records Open Amount, when it reads the next address book number Open Amount , I want the Orch input variable to reset.

Appreciate any suggestion. Thanks

 

[cazzafed]

Solo me estoy mojando los pies con Groovy y estoy tratando de averiguar si puedo usar Groovy para manipular la variable de entrada, que en última instancia es realmente una entrada de orquestación o una variable de orquestación. Digamos que quiero pasar una cadena a una solicitud personalizada Groovy muy simple y hacer que Groovy convierta la cadena en mayúsculas. No quiero una nueva variable en mayúsculas, quiero que la variable de entrada esté en mayúsculas. ¿Es esa la forma en que Oracle construyó el maravilloso gancho hoy?

I ask, with all due respect. Wouldn't this be easier to use?

import com.oracle.e1.common.OrchestrationAttributes;
import java.text.SimpleDateFormat;
HashMap<String, Object> main(OrchestrationAttributes orchAttr, HashMap inputMap)
{
  HashMap<String, Object> returnMap = new HashMap<String, Object>();
 
  String stringval = (String)inputMap.get("String");
    
  returnMap.put("UpperCase", stringval.toUpperCase());
  return returnMap;
}

 

[DaveWagoner]

Hi Dave, how can we reset the Orch input variable after it completes a loop.

My scenario is for a specific Address book number I am calculating the grand total by looping through the grid records Open Amount, when it reads the next address book number Open Amount , I want the Orch input variable to reset.

Appreciate any suggestion. Thanks

I think that as federicocazzaniga mentions above, it probably makes a good bit of sense to worry about what the original orch input var value is and just populate (and reset) a new variable name using script. In a case like yours where you are running through a big dataset with multiple keys and want to reset an accumulator when the key changes, you need a few to make it work well! prevKey, currentKey, runningAmount, and currentAmount. You would use a rule to compare prevKey to currentKey-- if same, then add currentAmount to runningAmount in a scripting component on one rule branch. If different, then set runningAmount to currentAmount using a different scripting component on the other rule branch. And outside of the rule branch, perhaps yet another scripting component to set prevKey to currentKey!

None of this involves worrying about the orch input var. Do you have a very specific reason to try to keep track of the orch input, and set/re-set it? I prefer to use more vars in my orchs and preserve original input variables in case I need them.

Hope that's helpful!

 

[Stank1964]

But, in my case, I do not want to create more variables. I want to manipulate the input as a
Lower case input has no value to me, in this case. If I need to retain the original value, I’ll create a new variable.

 

[DaveWagoner]

Let me show you how that *should* work. I'll re-use federicocazzaniga's script but change a couple of things..

import com.oracle.e1.common.OrchestrationAttributes;
import java.text.SimpleDateFormat;
HashMap<String, Object> main(OrchestrationAttributes orchAttr, HashMap inputMap)
{
  HashMap<String, Object> returnMap = new HashMap<String, Object>();
 
  String stringval = (String)inputMap.get("inputVar");
   
  returnMap.put("inputVar", stringval.toUpperCase());
  return returnMap;
}

Let's say your orch input var is called inputVar. Here we're taking an arbitrary input (to the script) named the same as orch input (so it will automap nicely ), and naming the output var to be the same as your orch input inputVar.

inputVar now matches what you set it to in the script, rather than what the orch input is. It's confusing because during mapping, and during setting orch output variables, it allows you to select BOTH inputVar values, as if each value was scoped to that specific component. It's confusing.

 

[Stank1964]

So I have been noticing that if you have a variable as output that matches exactly the variable name from an earlier step, it does seem to "overwrite" the original variable even if you map back to the orch input var later on in the orch flow.

Give it a shot! Name the output var from your groovy the exact same as the orch input var name. Test mapping a later step to the orch input first, and later, the groovy output. Should see if orchestrator essentially overwrites the orch input var if the vars are named the same.

Hi Dave.

Can you share your groovy code for this one? I can't make this work?

 

[DaveWagoner]

here's the entire orch! @Stank1964

 

[Stank1964]

This is interesting... Somehow the Orchestration input ends up crossed out with this kind of design when looking at the value with debug. I added a message step after the groovy. I wanted to get an email of the "inputVar" field. No matter if I map the "inputVar" as the ORCH input or the value coming out of the groovy script, inputVar is always upper case as delivered in the email. I like it. Thanks for sharing!

 

[DaveWagoner]

This is interesting... Somehow the Orchestration input ends up crossed out with this kind of design when looking at the value with debug. I added a message step after the groovy. I wanted to get an email of the "inputVar" field. No matter if I map the "inputVar" as the ORCH input or the value coming out of the groovy script, inputVar is always upper case as delivered in the email. I like it. Thanks for sharing!

View attachment 19700

Yup and this is you in Debug-- I think there's another spot where it tracks a given var's current and previous values. I think if you click that hamburger menu next to DAVE WAS HERE you get to see that.