我们在Siebel 7.8应用程序中遇到了一个非常奇怪的问题。
在Application_Start
事件中,我们定义了一组配置文件属性,这些属性决定是否允许登录的用户执行某些操作。代码是这样的:
if (userHasSuperpowers) {
TheApplication().SetProfileAttr("CanFly", "Y");
} else {
// CanFly is not set, and GetProfileAttr("CanFly") returns ''
}
除了其中一个配置文件属性外,一切都很好。条件不满足,所以我们不设置它的值。但当我们使用GetProfileAttr
检查时。。。它返回CCD_ 3而不是CCD_。
我已经检查了代码很多。我已经在各处放置了跟踪,并且我100%确信当Application_Start
事件的最后一行执行时,该属性仍然为空。但是,在登录后的第一个Applet_Load
事件中(在HLS Salutation Applet (HLS Home)
小程序中),其值已更改为'Y'
为什么我到处找过,但我找不到其他地方可以做SetProfileAttr
。到目前为止,我已经排除了:
- 所有我们的小程序、应用程序、BC和业务服务的每个浏览器和服务器脚本
- 所有运行时业务服务(直接在应用程序中而不是SRF中定义的业务服务)
Personalization Profile
业务组件字段- SmartScripts(并不是说它们在这个特定的场景中很重要,我提到它们只是为了承认你也可以在那里设置配置文件属性)
- 工作流:调用
SIS OM PMT Service
方法Set Profile Attribute
的每个步骤 - Siebel神奇地设定了它的价值。概要文件属性名称是用西班牙语定制的,它包含我们的项目名称和row_id。我真的不认为Siebel对自己的配置文件属性使用相同的名称:)
但是等等,还有更多,我把最好的部分留到最后:问题只发生在我们的开发环境中!
- 这不是SRF问题:如果我们在测试或生产环境中推广相同的SRF,它就会起作用并返回预期值
- 这不是数据问题:仍然使用相同的SRF,我可以使用我的本地厚客户端,使用相同的登录名和密码连接到我们的开发数据库,它也很好
- 这不是并发问题:我们只在一个用户登录的情况下进行测试。即使我们有更多的用户,他们也不会共享会话。即使他们这样做了,值也不会总是
'Y'
- 这不是暂时的故障,也不是由于错误的增量编译或损坏的SRF引起的:我们已经经历了至少6个月的这种情况(很明显,在这个时间段内,我们已经有几十个不同的SRF文件……所有这些文件都有相同的问题,但只有在开发中,并且只有当你使用服务器而不是专用客户端时…严重地…)
我还能在哪里搜索正在设置的配置文件属性我读到它们可以持久化到DB,但为了做到这一点,您必须将它们定义为基于S_PARTY扩展表的BC中的字段,对吗?
是否有任何方法可以以某种方式跟踪配置文件属性的更改?也许上升了一些逻辑水平?
在加载第一个小程序之前,我如何至少了解Application_Start
之后执行的内容?
还有其他想法吗?我也尝试过检查SQL假脱机文件,但也没有发现任何可疑之处(即,我们用来检查条件的任何查询,使用不同的参数运行两次)。
更新:根据Ranjith R的建议,我也检查了:
- 也可以从工作流中调用以设置配置文件属性的其他普通业务服务:
User Registration > SetProfileAttr
、SessionAccessService > SetProfileAttr
和ISS Promotion Agreement Manager > SetProfileAttributes
- 直接或使用业务服务设置概要文件属性的运行时事件(除了普通运行时事件之外,我们没有任何运行时事件)
- DVM调用的业务服务(我们只有普通的数据验证规则,没有一个适用于我们的buscomp)
仍然没有运气。。。
好的。。。最后我们发现了正在发生的事情:
- 我们访问服务器的URL并进入登录页面。这为
SADMIN
用户触发第一个Application_Start
事件 - 我们在该会话中设置了配置文件属性。
SADMIN
是Siebel管理员用户,所以是的,他是hasSuperpowers
,因此我们使用TheApplication().SetProfileAttr("CanFly", "Y");
Application_Start
事件结束- 我们在登录屏幕中输入用户名和密码以访问Siebel。这将触发第二个
Application_Start
事件,这次是针对我们的用户。这就是我用跟踪文件监视的那个 - 我们在新会话中再次设置配置文件属性。我们的用户没有
hasSuperpowers
,所以我们没有为CanFly
属性设置任何值 Application_Start
事件结束,并且CanFly
仍然为空- Siebel在加载第一个屏幕之前将两个会话合并为一个会话!!或者至少,它通过我们为
SADMIN
设置的配置文件属性进行传输
我相信事情是这样发生的,原因有两个。首先,我们更改了概要文件属性名称,以包含用户名。第二,我们现在存储的不是'Y'
0,而是当前日期:
var time = (new Date()).getTime();
TheApplication().SetProfileAttr("CanFly_" + TheApplication().LoginName(), time);
我们最终得到了CanFly_SADMIN
,但没有CanFly_USER
,并且存储的时间值与我们在步骤2的日志文件中看到的相同……它小于*_USER
属性的任何值。
所以事情就是这样。我仍然不知道Siebel为什么会这样做,但这将是另一个问题。根据Siebel书架:
启动事件在客户端启动时调用,在首次显示用户界面时再次调用。
但它并没有说明它是从两个不同的会话调用的,不同的用户也是,然后将它们合并在一起。考虑到在其他开发环境中不会发生这种情况,这在我们的开发环境中肯定是配置错误的。
Siebel 7.8有运行时事件吗?我想不起来了。运行时事件具有setevent的操作集,该操作集可以设置/清除配置文件属性。
还有其他普通的业务服务可以设置配置文件属性,尝试在工具平面下搜索*rofile*tt*
的业务服务方法。
SIS OM服务也可以直接从来自RunTime事件的DVM中调用,所以这也是可能的。
没有日志记录系统可以看到Profile Attributes的值发生变化,测试是唯一的出路。