Applies to:
Product Release: V7 (Enterprise)Version: 7.8.2.4 [19224]
Database: Oracle 9.2.0.4
Application Server OS: Microsoft Windows 2000 Server SP 2
Database Server OS: Red Hat Linux 8.0
This document was previously published as Siebel SR 38-3278900006.
Symptoms
SBL-DAT-00473 am getting below error when we are merging the records under Firstlogic DQ Admin Screen.
"No
Transaction is in Progress(SBL-DAT-00473)"
The steps I followed
1)
View-->SiteMap-->Firstlogic DQ Admin Screen-->Duplicate Accounts
2) Click on
Cable Alternative Technologies record. It is navigated to “Firstlogic Account Duplicates Detail
Batch View”
3) Top Applet shows “Parent Record” and Bottom Applet shows “Match
Records”
3) Merged two records first time, Merged records successfully
4) Tried to
merge another two records, Siebel is giving the above error
Solution
Message 1
For the benefit of others:SUMMARY:
Merging child accounts in Administration-Data Quality>Duplicate Accounts> Duplicate Account Resolution issues "No Transaction is in Progress(SBL-DAT-00473)" error.
If I try to merge records in Accounts screen the merge is successful.
RESOLUTION:
I have done the following test on Siebel 7.8.2.4 with Data Quality for SSA enabled:
1) Create AEG account
2) Create AEG child1, AEG child2 and AEG child3 all with AEG as parent account.
3) AEG child1 and AEG child2 accounts are detected as duplicate accounts for AEG child3 account.
4) Go to Administration - Data Quality > Duplicate Accounts, drill down on AEG child3 and try to merge AEG child1 and AEG child2. The "No Transaction is in Progress(SBL-DAT-00473)" error appears.
Looking in the error file:
"ObjMgrBusCompLog Error 1 0 2007-03-16 14:50:19 (odbccon.cpp (1944)) SBL-DBC-00111: An error has occurred writing to a record.
Please continue or ask your systems administrator to check your application configuration if the problem persists.
DBCLog DBCLogError 1 0 2007-03-16 14:50:19 SQLError: [23000],[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot insert duplicate key row in object 'S_DYNHR_RPT_REL' with unique index 'S_DYNHR_RPT_REL_U1'.
DBCLog DBCLogError 1 0 2007-03-16 14:50:19 SQLError: [01000],[Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been terminated.
more....
Message 2
more....ObjMgrBusCompLog Error 1 0 2007-03-16 14:50:19 (odbccon.cpp (1079)) SBL-DAT-00381: A record that contains identical values to the record you have created already exists. If you would like to enter a new record, please ensure that the field values are unique. "
This seems to be related to the table "S_DYNHR_RPT_REL" that is used for global accounts hierarchy.
I have logged Change Request # 12-1IPGQRX as a Product Defect to have the issue with merging child accounts fixed.
As a workaround for this issue you can do use one of the following suggestions:
1) Merge accounts in the Accounts screen
2) If you are not using global accounts feature you can use this workaround:
i) Go to Accounts> Global Accounts Administration and delete all existing account hierarchies.
ii) Go to Siebel Tools and inactivate the user property "Dynamic Hierarchy Parent Field Id" for "Account" BC then recompiled the SRF and test again the merge.
I tested and after this modification the merge is successful for child accounts also in Administration-Data Quality>Duplicate Accounts > Duplicate Account Resolution view.
Laura Doicin
Oracle | Siebel Technical Support
Keywords: merge accounts, merge child accounts, merge duplicate accounts, No Transaction is in Progress, SBL-DAT-00473
Applies to:
Siebel Connector for PeopleSoft Applications - Version: 7.5.3.7 [16190]Siebel Connector for SAP R/3 - Version: 7.5.3.7 [16190] and later [Release: V7 and later]
Siebel Connector for Oracle Applications - Version: 7.5.3.7 [16190] and later [Release: V7 and later]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.3.7 [16190]
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2000 Server SP 4
Database Server OS: Microsoft Windows 2000 Server SP 4
This document was previously published as Siebel SR 38-1475614341.
***Checked for relevance on 23-NOV-2010***
Symptoms
the following scenario caused data received from SAP to appear corrupted in siebel database:The customer upgraded to Siebel 7.5.3, and was using one SAP instance with multiple codepages to send data to Siebel. According to the Siebel SAP Connector documentation, one BAPIRcvr is able to receive data from any codepage supported by Siebel, and convert it according to the login of the sender.
However, he found that there would be corrupted Siebel data when the BAPIRcvr processed an English IDOC and then a non-English IDOC (i.e. Japanese or Korean IDOC). Even though BAPIRcvr did not error out, the double-byte SAP data did not appear correctly in his Siebel database. The Siebel database was Unicode enabled and could hold Japanese, Korean and English data. The customer also noticed that if the BAPIRcvr only received IDOCS from one codepage (i.e. all Japanese), there was no data corruption. Or if he received a Japanese IDOC and then an English IDOC, there was no corruption either.
Cause
We had the customer confirm that the IDOCs did not have mixed codepage data. The customer verified he was testing and sending known data with specific logins. The reason we asked for this verification is because SAP does not check that the data is only in the codepage of the login user.So it is possible to login into SAP in Japanese and create a product with a description that is in Japanese. Then log out and log in again in English and send that Japanese product to Siebel. The Siebel BAPIRcvr will think the IDOC is all in CP1252 because of the English user's login. As a result, the BAPIRcvr may garble up the data or may have an error depending upon whether or not there is a match for the specific characters passed to Siebel in the CP1252 code page.
After receiving the rfc trace from the customer and further testing, we found the cause of the data corruption was due to the BAPIRcvr not immediately retrieving the codepage from SAP for the second IDOC. Hence the second IDOC was partially converted in the codepage of the first IDOC. We opened change request 12-OW80FX for this behavior and fix request 12-OWZYLF for a future Siebel 7.5.3.x maintenance release to contain the fix.
Solution
The workaround to ensure the data does not get corrupted is to run copies of the BAPIRcvr for each individual language, i.e BAPIRcvrKO, BAPIRcvrJP. So it is necessary to set up the SAP and Siebel configuration so that there is a one to one correspondence between each RFC Destination and Siebel BAPIRcvr.After the customer reconfigured his Siebel and SAP environments, he was able to successfully process almost all his Japanese and Korean IDOCs. He did have a few IDOCS that he could not send to Siebel. In transaction SM58, he would see this error "Failed to retrieve data from SAP raised by external server" for those IDOCs. In the BAPIRcvr log, he would see these errors:
GenericLog GenericError 1 TranscodeFailure (Encoding=CP949, NumErrors=1, InvalidPosition=213): ByteArray
ObjMgrLog Error 4 (SBL-EAI-04419) Transcode Conversion Failure
ObjMgrLog Error 4 (SBL-DAT-00473) No transaction is in progress
The first message usually means there is an error in the input data, such as there is a value in the data given us from SAP that is not CP949. The customer copied and pasted the data on the SAP screens and resent the IDOC, and no longer encountered the error. So we suspected there may have been a few records with data that was not encoded correctly.
More details on the SAP configuration that the customer created:
He defined new logical systems and RFC destinations that are codepage specific, i.e. a logical destination for the Japanese data and another one for English data. Then he built a way in SAP to send data to specific logical systems depending upon codepage/language used in SAP. He had an ABAP program that ran in batch mode. This program queried an internal SAP table to find a list of customers that need to be sent to Siebel, and submitted the customers to the appropriate RFC destination based on the customer's language.
If you are sending IDOC of type MATMAS, you could use the standard filter group which includes language code. So you could configure a MATMAS language filter by specific codepages, and use the standard ALE transactions (i.e. BD10) to send the IDOCS at once to all logical systems. Then you could let the ALE-layer filter them according to the logical system/RFC Destination.
References
BUG:12-OW80FX - BAPIRECEIVER DOES NOT RETRIEVE CODEPAGE FROM SAP WHEN RECEIVING ENU THEN JPN DATAApplies to:
Siebel CRM - Version: 8.0 [20405] to 8.1.1 [21112] - Release: V8 to V8""""Checked for relevance on 29-OCT-2010""""
Symptoms
JMS_EXCEPTION at impersonated (SecureWebService) Inbound WS call processed by JMS Received causes inconsistent behavior: message data are updated in Siebel Db, but message self rolled back into input JMS Queue.
The behavior appears in the following sequence:
1. The JMS Receiver is set to dispatch all received message by the "SecureWebService" named subsystem (EAI Data Handling profile);
2. External application puts a message with SOAP XML request into the JMS Queue. The SOAP Header of the request includes WS-Security fields with Siebel user credentials;
3. The JMS Receiver pick ups the SOAP XML message from the JMS Queue;
4. The JMS Receiver impersonates the user (changes its session context to the specified Siebel User), by the information from WS-Security fields in the SOAP Header;
5. The received SOAP Request is get dispatched to accordant Inbound Web Service implementation (a business service or a workflow process);
6. The Web Service implementation completes the processing (for example updates or/and queries Siebel Data)
7. The EAI Transaction commits the updates in Siebel Db.
8. The JMS Receiver fails to commit the message processing to the JMS Queue (to remove the message from the Queue), because of the raised "JMS_EXCEPTION" java error without detailed information.
9. As result the message stays in the JMS Queue and can be picked up by JMS Receiver again for processing, disregarding of successful completion it at previous run.
10. The Siebel Db is updated, while the JMS Messaging Provider does not receives positive sign to remove the processed message from the JMS Queue as "committed".
* * *
This behavior has been reproduced in 8.0.0.6 SIA and 8.1.1 SIA products and may affect other 8.x Release.
The traces appearing in the JMS Receiver log (8.0.0.6 [20423] ENU) were:
"...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Begin: Business Service 'Web Service Inbound Dispatcher' invoke method: 'Dispatch' ...
...
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Envelope Processing
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Impersonate
...
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Executing web service operation '...' by calling ...
...
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Completed inbound web service execution.
...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'Web Service Inbound Dispatcher' invoke method: 'Dispatch' ...
EAITransport EAITransportGenericEAITransportGeneric 3 ... Dispatch Service: 'Web Service Inbound Dispatcher', Method: 'Dispatch' completed successfully
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Business Service 'EAI Transport Dispatch Service' invoke method 'GenericDispatch' ...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'EAI Transport Dispatch Service' invoke method: 'GenericDispatch' ...
ObjMgrBusServiceLogObjMgrBusServiceLog Delete 4 ... Business Service 'EAI Transport Dispatch Service' ... was unregsitered ...
ObjMgrBusServiceLogObjMgrBusServiceLog Delete 4 ... Business Service 'EAI Transport Dispatch Service' was deleted ...
ObjMgrSessionLogObjMgrSessionLog Warning 2 ... (physmod.cpp (4998)) SBL-DAT-00473: No transaction is in progress
ObjMgrBusServiceLogObjMgrBusServiceLog Create 4 ... Business Service 'EAI JMS Java Business Service Caller' was created ...
ObjMgrBusServiceLogObjMgrBusServiceLog Create 4 ... Business Service 'EAI JMS Java Business Service Caller' ... was regsitered ...
EAITransport EAITransportDebugEAITransportDebug 4 ... Invoking JMS Java method Commit
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Begin: Business Service 'EAI JMS Java Business Service Caller' invoke method: 'Commit' ...
...
EAITransport EAITransportDebugEAITransportDebug 4 ... Finished copying properties
EAITransport EAITransportDebugEAITransportDebug 4 ... Finished copying type
EAITransport EAITransportDebugEAITransportDebug 4 ... Finished copying value
EAITransport EAITransportDebugEAITransportDebug 4 ... End Creating instance of output property set
...
ObjMgrBusServiceLogObjMgrBusServiceLog Error 1 ... (javabsvc.cpp (181)) SBL-EAI-05000: Business Service call returned error code JMS_EXCEPTION and message: An unexpected error occurred (see StackTrace): null
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Business Service 'EAI JMS Java Business Service Caller' invoke method 'Commit' ...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'EAI JMS Java Business Service Caller' invoke method: 'Commit' ...
ObjMgrBusServiceLogObjMgrBusServiceLog Error 1 ... (jmsbsvc.cpp (323)) SBL-EAI-05103: A JMS exception occurred in EAI JMS Transport: 'An unexpected error occurred (see StackTrace): null'.
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Business Service 'EAI JMS Transport' invoke method 'ReceiveDispatch' ...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'EAI JMS Transport' invoke method: 'ReceiveDispatch' ...
..."
The SOAP XML Request was made like the example below:
<s:Header>
<ws:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
<ws:UsernameToken>
<ws:Username>...</ws:Username>
<ws:Password ..>...</ws:Password>
</ws:UsernameToken>
</ws:Security>
</s:Header>
<s:Body>...</s:Body>
</s:Envelope>
Cause
We presume, that user context change used in the impersonation approach at each incoming Web Service call caused reset of outstanding transaction flags.
Working without user context changing prevents occurrence of the behavior.
The Change Request Bug 12-1SW8CDR has been logged to address this case.
Solution
1. WORKAROUND, verified for Siebel 8.1.1 Release:
Change the impersonation approach to use Siebel specific fields in the SOAP Header to send user credentials. The SOAP XML request should be made like the example below:
xmlns:s2="http://siebel.com/webservices" ...>
<s:Header>
<s2:UsernameToken>...</s2:UsernameToken>
<s2:PasswordText>...</s2:PasswordText>
<s2:SessionType>None</s2:SessionType>
</s:Header>
<s:Body>...</s:Body>
</s:Envelope>
This workaround may not help in Siebel 8.0 Release.
2. WORKAROUND, verified for Siebel 8.0 and Siebel 8.1.1 Release:
Change the intgeration approach to not use impersonation feature for Inbound Web Service calls (SOAP XML requests), received and processed by the JMS Receiver task.
Using of the "WebService" EAI Data Handling subsystem will keep the integration working. The only side effect of this solution is that the context of the JMS Receiver user (specified in the component parameters) will be used for processing of all messages.
References
BUG:12-1SW8CDR - JMS_EXCEPTION AT 'COMMIT' OF 'EAI JMS JAVA BUSINESS SERVICE CALLER' FOR INBOUND WS WITH WSSE-AUTH.NOTE:850954.1 - Basic Troubleshooting Steps for EAI JMS Transport
NOTE:1076251.1 - Master Note for Siebel Web Services
No comments:
Post a Comment