Siebel UI merge which uses the "UCM Process Merge Request" workflow process fails/does not merge the parent nor children records when "CUT Address" BC [Address Geography Id] field is inactivated
(Doc ID 1959442.1)
Last updated on MARCH 02, 2017
Applies to:Siebel CRM - Version 184.108.40.206.10 [IP2013] and later
Siebel Universal Master - Version 220.127.116.11.10 [IP2013] and later
Information in this document applies to any platform.
*** Checked for currency on NOV-01-2016 ***
Siebel Siebel 18.104.22.168
In the out of the box Siebel application, the "CUT Address" BC [Address Geography Id] field is active by default.
However, in this customer's case, they had inactivated the field for unknown reasons which they were not aware of at the time. As a result of having this field inactivated, whenever customer performed the Siebel UCM UI Merge of two records, which invokes the underlying "UCM Process Merge Request" workflow process, the merge would fail/not merge the parent nor children records with a very peculiar pattern. For example, this is the test case performed by customer and Oracle Support internally, which generates the following results pattern:
1. Inactivate the [Address Geography Id] field on "CUT Address" BC inactivated, compile object to the server srf file.
2. Create 6 accounts all with same address but different site and contacts, example:
Site: EDD0N N is a number, 01, 02, 03, 04, 05, 06
Address: 4500 Oracle Ln, Pleasanton, CA, 94588
Each has 2 different contacts (child data) associated to the account.
Account 1: Contact1A, Contact1B
Account 2: Contact2A, Contact2B
Account 3: Contact3A, Contact3B
Account 4: Contact4A, Contact4B
Account 5: Contact5A, Contact5B
Account 6: Contact6A, Contact6B
3. Verify the "UCM Process Merge Request" workflow process and subprocesses, etc. are enabled.
4. Perform these merge test cases using Siebel UCM web client:
a. Log into the client application > UCM Screen > Existing Duplicates View > select EDD02 > drill down > it matches with EDD01 > click Merge button > check the results > Log out
It did not do the merge:
- Account EDD01 is still there with the 2 contacts Contact1A, Contact1B
- Account EDD02 is still there with its 2 contacts Contact2A, Contact2B
Check log file ...
PrcExec PropSet 4 00000092548f1608:0 2014-12-15 14:47:05 Getting runtime value of property 'Namespace: 'USER' Name: 'ObjectType' Datatype: 'String''.
PrcExec PropSet 4 00000092548f1608:0 2014-12-15 14:47:05 Getting runtime value of property 'Namespace: 'USER' Name: 'SurvivorId' Datatype: 'String''.
PrcExec PropSet 4 00000092548f1608:0 2014-12-15 14:47:05 Getting runtime value of property 'Namespace: 'USER' Name: 'VictimId' Datatype: 'String''.
StpExec Task 4 00000092548f1608:0 2014-12-15 14:47:05 Invoking method 'MergeChildren' on business service 'UCM Merge Service'.
StpExec TaskArg 4 00000092548f1608:0 2014-12-15 14:47:05 Input: @0*0*3*0*0*0*7*MatchId7*1-1BU2H8*MasterId7*1-1BU3710*ObjectType7*Account
... a bunch of update statements using the db table layer merging ...
ObjMgrBusCompLog Warning 2 00000092548f1608:0 2014-12-15 14:48:19 (sqlbcdef.cpp (3585)) SBL-DAT-00398: Field 'Address Geography Id' does not exist in definition for business component 'CUT Address'.
Please ask your systems administrator to check your application configuration.
ObjMgrBusCompLog Delete 4 00000092548f1608:0 2014-12-15 14:48:19 BusComp "DeDuplication Results (Account)" at 13625148 was deleted
ObjMgrBusCompLog Delete 4 00000092548f1608:0 2014-12-15 14:48:19 BusComp "Dynamic Hierarchy" at 1f5a49f0 was deleted
ObjMgrBusCompLog Delete 4 00000092548f1608:0 2014-12-15 14:48:19 BusComp "Account" at 16c2f138 was deleted
ObjMgrBusCompLog Debug 5 00000092548f1608:0 2014-12-15 14:48:19 CSSBCBase::PreMerge - END
ObjMgrBusServiceLog InvokeMethod 4 00000092548f1608:0 2014-12-15 14:48:19 Business Service 'UCM Merge Service' invoke method 'MergeChildren' Execute Time: 73.650 seconds.
ObjMgrBusServiceLog InvokeMethod 4 00000092548f1608:0 2014-12-15 14:48:19 End: Business Service 'UCM Merge Service' invoke method: 'MergeChildren' at 18126f38
StpExec TaskArg 4 00000092548f1608:0 2014-12-15 14:48:19 Output: @0*0*0*0*0*0*
StpExec Cond 4 00000092548f1608:0 2014-12-15 14:48:19 Step branch 'Connector 14' passed.
StpExec End 4 00000092548f1608:0 2014-12-15 14:48:19 Stopping step instance of 'Merge Children' with a 'Completed' status.
StpExec Create 4 00000092548f1608:0 2014-12-15 14:48:19 Instantiating step definition 'Check SE On?'.
When the error occur, we are not able to see any SQL update statement which were failing on the GEOGRAPHY_CODE column that the 'Address Geography Id' field is mapped to, so unclear why inactivating this field would generate an issue.
b. Now, log into a new client session and merge EDD03 with EDD05, this time it worked fine, all contacts from EDD05 merged into EDD03.
Checked the log file:
For this case, it doesn't have the error "SBL-DAT-00398: Field 'Address Geography Id' does not exist in definition for business component 'CUT Address'."
Log out of this client session.
c. Log into another client session and merge EDD06 with EDD04, it did not merge, the log shows the error:
Log out of this client session.
d. Log into another client session and merge EDD06 with EDD05, it works fine, all contacts are under EDD06 now.
Log doesn't show the error.
Log out of this client session.
- We can't see in the log file where the field 'Address Geography Id' is being used nor see the underlying GEOGRAPHY_CODE being referenced in any of the update statements that are issued.
- The other strange thing is that this works/fails in alternative patterns, every other time/attempt. Ie. fails, works, fails, works. Or, works, fails, works, fails.
- The above issue/pattern occurs no matter if the user logs into a new client session each time to do each merge; or if the user uses the same client session for all merge attempts, the issue/pattern happens in both scenarios with new session login/logout or same sessions usage throughout.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document
|This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.|