这些数据结构都维护在内存中,目前无持久化。
位置:wsServerforWebShop.js
oTransactionID_SiteDetailMap每次webshop的KOI login按钮点击之后,服务器会生成一个新的session,同时在这个数据结构(类似于hashmap)里插入一条记录:
key:transaction id

value:主要有data和dataFromWebShop两个对象。
data对象里只有一个字段QRCode,值和这条记录对应的key相同。

dataFromWebShop对象包含了该webshop的名称,和支持的Consent字段,上图表明Nike webshop支持firstName,lastName和email三个字段。
clientAddress:该WebSocket服务器作为TCP客户端和Orchestra连接的IP地址。
clientSocketID:同该WebSocket服务器建立ws连接的webshop对应的套接字。
oKOIID_TransactionIDMap每次KOI App点了confirm按钮后,会生成一个ConfirmRequest的请求,请求数据里包含了该user的KOIID,因此后台会把这个KOIID同ConfirmRequest里附带的Transaction ID做绑定。这样接下来user在KOI App上进行Global profile update的时候,后台就知道应该把这些update请求dispatch到哪些Web Shop实例上。

逻辑就是通过KOIID找到所有的transaction ID,通过transaction ID和刚刚介绍的数据结构oTransactionID_SiteDetailMap即可找到每个关联的web shop实例。
oGlobalProfileValueUpdateNotificationTaskQueueKOI App发送的Global profile update请求,即下图左边的简化示意图,被后台服务器处理后,成为下图中间的数据结构:

在代码中的一个例子为:

这个数据结构会进一步被加工为可以直接发送给每一个相关的WebShop实例的数据,最终待发送的数据结构如下图:
