We are trying to run a situation where initially the chat interaction is being processed in ORS, then we call a strategy from URS that attaches some data to an interaction which is then passed back to ORS for further processing.
Can anyone give me any tips on how to maintain attached data between ORS and URS?
LOL - fair response. I am just going to rerun a test we are doing then I will explain in more detail. Its slightly more complicated than I may have indicated. Appreciate the response though.
Ok so an extremely interesting question which if I had enough character space to fill in the details I would. ;D I can try… but will do so later. Its very complicated. The issue we are having is if we attach something in URS and then pass the interaction back to ORS the attached data is no longer present.
OK gonna run some more tests today in our dev environment. And I’ll see if I can gather some log extracts to share. So what on earth am I trying to do? This is going to take some explaining but here we go…
We are using GWE. When our team (can I just state I was not involved in this decision) decided to build the strategies to be used for the project, they chose to take the out of the box Genesys provided Web Engagement strategies (for the playground app) and then add and change stuff inside those strategies to suit our business need. They then called them our strategies ;D
There is one major flaw in this we have discovered. The Genesys GWE Composer strategies have limited functionality and do not actually contain all the code necessary to make all the Composer functions work properly. Take DBData Dip for example. We added a DB dip into the strategy in Composer and it failed. Turns out all the jsp’s you need to get the DB Dip to work are not automatically packaged within the backend.war and you have to add them manually - Genesys PS sorted this out for us.
So all in all we were in a good position ready to use the DB Data dip inside ORS. On to the second issue, turns out that when ORS executes the scxml for Web Engagement, it actually not only calls the scxml from backend server, it also executes some of the scxml there as well. Including the DB Data Dip object. So in order for the DB Data Dip object to work I need a connection from my backend server to my UCS.
Have you fallen asleep or are you still with me?
I cannot give a connection from backend server to my UCS database for security reasons. I do not want to compromise myself here, but it is a connection we do not want to open up. Affectively my backend server is on a different network to my ORS, or my UCS database.
So I have two solutions
Make ORS do the DB Dip locally. So sounds simple enough but due to the fact we have used the Genesys strategies as our template, and the DB Data Dip took so much work to get working as it is, I feel this might actually be the harder option
Get URS to do the DB dip to UCS for me and carry the attached data back to ORS.
So I am trying option 2, but failing quite horribly in our dev environment. Promise log extracts to follow, I haven’t worked on it for a few days as it has a lower priority than some of the other stuff I am working on.
So you did ask! ;D I hope I haven’t bored you to death.
“I then make a WebRequest to URS to kick off the DB Dip strategy…”
How exactly you do it? Specifivally how this web request associated with interaction with changed user data?
TOTAL change of plan! Discovered an Option 3, which is so much easier. Forget using URS at all, I am now trying to retrieve data from CS for the Category Structure, Business Attribute instead of doing a dip into UCS.
This should be much easier. I am using the function gdata. However, syntax seems to be giving me issues. I keep getting an Invalid Label error.
The gdata function is using the following expression - varCannedResponse = category folder name in KM
gdata::/config/CA-BA.varCannedResponse/“annex”/General/id