seems same issue

seems like a defect, i would log a defect and fix it in subsuquent release

yes, the tag has to be unique

You can map both the strings to you "Multiple string", ED should make an array with two strings

In 3.2 onwards there is no tasks-snapin

you have to run mvn install and not mvn package

jar is produced in tasks/target, you have to go to ED admin console -> bundles and upload the jar there

Hi Andrew, this is harmless error. ED is trying to get attributes configured in SMGR based on service profile. In your case there may not have been a call and so ED should not have tried to look up the service profile. This is fixed now in later codes of ED

Thanks for the information on lab 158, and nice it worked for you, we may not need lab (this is easy to reproduce)

seems like a bug in latest ED code, parseInt should be allowed with just string or string and radix

Seems like just string s broken for now, i would log a defect

in meantime you can use string, 10

TelemetryObject["data"][4]["floatValue"] > parseInt( Properties["TempMax"], 10 )

In Extra Functions, there is parseInt(String)

you can use

TelemetryObject["data"][4]["floatValue"] > parseInt( Properties["TempMax"] )

In 3.1.0.2, there should be a cba

Is there a cba generate under tasks-snapin/tasks-snapin-cba/target ? what is the version of this cba ? Is it the same version and ba that is used in svar's pom.xml

Hi,

If you are working with ED 3.2 then the above dev guide is obsolete, there would not be any cba in 3.2

There should be a jar file in tasks/target directory

You have to use that jar, go to admin console->bundles and upload it there

Regards

yes, otherwise there is no way of knowing what ucid should be used in particular task. Please see it as general data issue. Even for the ucid,

* a workflow may deal with more than two calls
* ucid may not be called ucid always (we may use that convention, but we allow third part tasks which may not use that convention)

probably in case of ucid, we can assume it always come from start schema, but in case of other data - we need to specify which variable and which part of variable contains the data

Hi Andrew,

ED has two kind of data things, variables and input/output of each task

StartSchema is a variable, variables are available/scoped across whole workflow

CallEvent:ucid is input to a task, it is only available in that task and tasks output can be mapped to any of the variables in that workflow

In your case you may want to always use StartSceham:ucid as value of CallEvent:ucid and that may be true for ucid, but not true for other things

some values may be computed by some other task (say database task ) in middle and set on some variable (like the phone number to call to may come from db and called mobile in database), now some call task may want to use it in outgoing call. General way is do output mapping from database task to some varaible and later input mapping from varaible to call task

There is a component in EDP called Eventing Connector which provides a POST interface, please see the attached image for example. You have to provide event type/ family, payload

Patrick, I am able to verify/reproduce the issue. We are using javascript scripting engine from java and when we passed /^0+/ - the javascript engine took it as string literal rather than regular expression

I have made a code fix for this, I do not know the release vehicle