| Anonymous | Hello,
Not sure why no one has responded to this post so I am going to! Better late than never right? 8-)
Yes you are correct, if you have 3 XML Decision elements that each use the same XML content you would have to make 3 copies of the XML and once you change 1 you would have to change all of them.
And yes, element groups could be a good solution to this. You would make an element group that basically only contains that decision element and then save it as a template. Now, you can update the template when you need to make a change and every time you bring over the element group into an application it would reflect the latest version of it. The big problem here is that all the copies of this element group you have copied over prior to the change still reflect the old XML.
So if you want to have literally a "singleton XML decision" then there is no easy option in today's software. I guess what you could do is create an application whose contents are just this decision and then perform an application transfer to that application and pass some variable that would tell you where in the callflow you came from so that when the singleton application transfered back you would have a decision at the top of the callflow that would look at that variable to know where to go next. Kind of ugly but it would do what you want.
To expand on your suggestions, one could conceive of an XML decision "repository" that when you are creating a new XML Decision could simply reference instead of writing your own. I'll go ahead and put that into our system as a feature request. |
| Please sign in to flag this as inappropriate. |