Can someone explain exactly how I should be using input and output mapping? I recently saw a demo of EC where the presenter mapped CallEvent:ucid to StartSchema:ucid. Ucid was eventually used to drop the call.

My question involves all the middle elements that might be part of the workflow. Do I continue to map ucid as part of the input mapping on each one of those (e.g. Play Announcement)? I get validation errors if I don't, but it seems as if I map it at the beginning into StartSchema that should be good enough. It seems tedious to keep doing it over and over again for each element. Am I missing something? Is there a better way?

I looked at the Developer's Guide and it was not very helpful in this regard.

Thanks!

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

Does that mean I need to map ucid into each task in the workflow? For example, in a simple workflow of Start, Play Announcement, Drop Call, End, would I need to do the following?

In Start Output Mapping: CallEventObject:ucid --> StartSchema:ucid

In Play Announcement Input Mapping: StartSchema:ucid-->PlayAnnouncementInputSchema:ucid

In Drop Call Input Mapping: StartSchema:ucid-->DropCallInputSchema:ucid

Yes, you do. I've been thinking for a while about adding an enhancement request such that:
- IF the start event is a call event or call intercept event AND
- The UCID input parameter to a task is not mapped THEN
- The UCID from the start event will be used by default.

As Anurag mentioned, there are cases where the mapping will be required. I've seen several workflows that work with more than one concurrent call, so you need to be able to tell the task which call to operate on. In far more workflows, however, it's just overhead.

Thanks Andrew. I'm going to write that enhancement request now.

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

Thanks! I approve of your enhancement request. The current way seems like a lot of overhead for something that could easily be assumed.

Right now, I am only doing this with ucid. Should I be paying attention to the other values or are they only needed when I specifically need to access or modify them?

It depends on your use case. In some cases, you'll be fine either leaving values blank (accepting the default) or by populating them statically through the properties on the task dialog box. Let me give you an example with text to speech.

In many cases, it works just fine to type the contents of a TTS announcement into the "URL" property in the Play Announcement or Prompt and Collect dialog box. However, in the near future, it will be possible to launch a workflow on receipt of an email or SMS. When that is supported, it may be desirable to use some text from the body of the email / SMS as the text to be voiced out. In that case, you'd use output mapping to map the contents of the incoming SMS / email to a business process variable (if it's a start event, those values are automatically mapped to the Start Schema variable). You'd then map from the BP variable to the URL input parameter on the Play Announcement task type.

By the way, it's also possible to define your own custom events in the catalog and then launch workflows when those events are received via REST. In that case, values from those custom events can be extracted and supplied as input parameters to later task types.