I am extending the interaction schema to add a new attribute called ccAgentId to store the call center agent id. While making SOAP call, the call center application will send the string agent Id.
So I started following the instructions as mentioned into the document Extension example
After making the changes in interaction and proposition schema, I updated the offer space as below to store the ccAgentId sent via the propose method
I am making the call and passing the attribute as below. But the extension value is not getting saved into the proposition schema (proposition is saved but the extension column is blank).
<urn:context>
<!--You may enter ANY elements at this point-->
<context>
<interaction ccAgentId="TarunG" />
</context>
</urn:context>
I have the interactiond process running on the instance. I really don't know what this process actually does other than some very high level info I saw in the documentation. A side question, is this even required to run if I have just one instance (control instance) running? Also if I have multiple servers, do I need to run it on all the servers? I don't have any separate execution instance as of now.
Coming back..
After further debugging the interaction.js and the code generated by offer space, I got the option variable NmsInteraction_UseDaemon
When you keep the variable = 1 (default), the "if" part is executed and when =0, then else part (below code)
sInsertOrder = this.buildInsertMem(propositionSchemaRoot, linkPropToTarget, this.sTargetSchema)
else
sInsertOrder = this.buildInsertSQL(propositionSchemaRoot, linkPropToTarget, this.sTargetSchema)
Now, the first part of the if creates the code as below which has the part of ccAgentId as highlighted.
interactionInsertProp(propositionId, id, 21043, props[0].id, iDeliveryId, proposition.weight, proposition.rank, proposition.status, String(ctx.@['id']).replace(/\\/g, '\\\\').replace(/:/g, '\\:'), (index == iLen-1 ? aNextOffers.join(",") : ""), (index == iLen-1 ? aNextOffersWeights.join(",") : ""), "sCcAgentId,6," + String(ctx['interaction']['@ccAgentId']), (index == iLen-1 ? sTotalTime : 0), (index == iLen-1 ? sInitHookTime : 0), (index == iLen-1 ? sSessionCookieTime : 0), (index == iLen-1 ? sPermCookieTime : 0), (index == iLen-1 ? sTargetLoadTime : 0), (index == iLen-1 ? sVisitorLoadTime : 0),(index == iLen-1 ? sTargetLoadHookTime : 0), (index == iLen-1 ? sExistsRulesTime : 0), (index == iLen-1 ? sPropHookTime : 0), (index == iLen-1 ? sMicroEngineHookTime : 0), (index == iLen-1 ? sPostPropProcessTime : 0), (index == iLen-1 ? sTypologyTime : 0));
For the else part, it creates a statement with sqlExecOnDataSource function to execute the sql directly into the database as below and it has the part for ccAgentId too.
sqlExecOnDataSource("insert into NmsPropositionRcp (iPropositionId,iOfferId,iOfferSpaceId,iInteractionId,dWeight,iRank,iStatus,tsEvent,tsLastModified,iEngineType,iDeliveryId,iRecipientId,sCcAgentId) values ($(l),$(l),21043,$(l),$(d),$(l),$(b),$(curdate),$(curdate),1,$(l),$(l),$(sz))", "default", propositionId, id, props[0].id, proposition.weight, proposition.rank, proposition.status, iDeliveryId,ctx.@['id'], String(ctx['interaction']['@ccAgentId']));
Now the confusing part is, when the option variable is set to 0 (default one), the ccAgentId is not saved where as when option var = 1, it is saved properly.
That means, with the direct SQL, it is working fine whereas the asynchronous processing is not saving the data. I fear, if I do the synchronous insert statement, I will have trouble when Millions of calls will come in an hour as everyone will try to lock the table for insert/update [Same details I notices for Update method as well].
Can someone please help me to understand what is happening inside and how can I have it working with default value for the option variable.
Solved! Go to Solution.
Hi,
Hard to say, looks like what you have is correct here. This part is a bit off-script:
<context>
<interaction ccAgentId="TarunG" />
</context>
Documentation says use <empty/> for the child node of <context/>, though really should be fine either way.
For perf tuning, I haven't messed with any of those params; never could figure out what they did or how they'd have an impact.
The Inbound Interaction module is cleverly designed for horizontal scaling: in that queries are run in js on the app servers, not the db, which is only consulted once for a single recipient row to process all the non-anonymous offers against. If your app servers are showing high load in benchmarks, just add more of them. If the db is overloaded, make sure join keys have indexes etc, and in a worst-case scenario look to replication strategies such as Power Cluster(tm).
Thanks,
-Jon
Hi,
Nothing confusing. The interactiond daemon's entire purpose is to record interaction logs, asynchronously, and needs to be active on all servers you want to record logs from. Interactiond's performance is tuned via its buffer allocation.
Thanks,
-Jon
Hi Jon,
Can you please let me know why the value of the additional data (ccAgentId in my case) is not saving with the daemon enabled? I have interactiond process running on the servers. Also can you please share more details how it works? When you make the update status, does it store the data into any queue or memory buffer and then every second it is processes?
Also for the configuration "callDataSize : Max. number of characters stored in the shared memory for call data Default: 0", can you provide more details.
Any suggestion for optimum values below parameters with customers having 25M members and 200 live offers
callDataSize
maxProcessMemoryAlertMb
maxProcessMemoryWarningMb --> Probably 75% of above
maxSharedEntries
nextOffersSize
runLevel
Views
Replies
Total Likes
Hi,
Hard to say, looks like what you have is correct here. This part is a bit off-script:
<context>
<interaction ccAgentId="TarunG" />
</context>
Documentation says use <empty/> for the child node of <context/>, though really should be fine either way.
For perf tuning, I haven't messed with any of those params; never could figure out what they did or how they'd have an impact.
The Inbound Interaction module is cleverly designed for horizontal scaling: in that queries are run in js on the app servers, not the db, which is only consulted once for a single recipient row to process all the non-anonymous offers against. If your app servers are showing high load in benchmarks, just add more of them. If the db is overloaded, make sure join keys have indexes etc, and in a worst-case scenario look to replication strategies such as Power Cluster(tm).
Thanks,
-Jon
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies