Applies to: Siebel Connector for SAP R/3 - Version: 7.0.4 [14068] to 8.1.1.2 [Release: V7 to V8]
Microsoft Windows (32-bit)
This document was previously published as Siebel SR 38-2042838531.
SymptomsCustomer configured standard Siebel 7.5. CRM to SAP 4.x R/3 (outbound) Integration for Accounts.
While testing the integration (clicking "Submit" button in the "Accounts->Back Office (SAP)" View),
the call of the "EAI SAP BAPI Adapter" BS has reported the following error :
"...
GenericLog GenericError 1 0 ... TranscodeFailure (Encoding=ISO-8859-5, NumSubstitutions=1, InputSubstPosition=120, OutputSubstPosition=60): DEST=DEV_OUTBOUND CLIENT=300 LANG=E USER=SIEBELUSER PASSWD=????
..."
Errors reported around this failure were: SBL-EAI-04419, SBL-EAI-04420, SBL-EAC-00158
Cause
Inconsistent in Code Page translations from Siebel to SAP
Solution1. On "Business Integration Manager"and "SAP BAPI tRFC Receiver" components, it was made sure that the following parameters were set correctly:
SAP Ignore Char Set Conversion=True
SAP RFC Connect String=
SAP RFC User Name=
SAP RFC Password=
SAP Codepage=ISO-8859-5
SAP Sender Partner Number
2, In Siebel application > Administration-Integration > EAI Value Maps,
following values for type "SAP Codepage" were set (added for Siebel 7.5):
(SAP - Siebel)
1500 - ISO-8859-5 (Russian)
3. SAP Code page were set to 1500
4. The user property: "SAPInitialSystemCodePage" was changed from “Local†which is default for all SAP Business Services ("EAI SAP BAPI Adapter (tRFC)", "EAI SAP BAPI Adapter", "EAI SAP BAPI Receiver (tRFC)", "EAI SAP IDOC Adapter") to “ISO-8859-5â€.
Amended Business Services were compiled into the .SRF of the Siebel Server.
* * *
Information to SAP Code page configuration approach can be found in Siebel Bookshelf Document:
"Siebel Connector for SAP R/3", Chapter: "Installation and Configuration" , Section: "SAP Code Page Configuration". For Siebel Release 8.1.
Applies to: Siebel System Software - Version: 7.5.3.4 [16180] and later [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3.4 [16180]
Database: IBM DB2 8.1 FixPack 3
Application Server OS: IBM AIX 5L 5.1
Database Server OS: IBM AIX 5L 5.1
This document was previously published as Siebel SR 38-1828283021.
***Checked for relevance on 17-JAN-2011***
SymptomsA customer was sending Quote Id to external application using EAI HTTP Transport business service. The external application expected the sending data was encoded in UTF-8 so that the CharSetConversion input argument was set to UTF-8 when calling the EAI HTTP Transport.
Then, external application sent back a response message in binary stream to Siebel application but no response message was received by the EAI HTTP Transport. A binary data type process property was used to receive the response message but it did not make any difference.
To isolate the root cause of the reported behavior, a detailed log file was generated and the following error was found when receiving the response message:
GenericLog GenericError 1 2005-03-17 14:08:56 TranscodeFailure (Encoding=UTF-8, NumErrors=1, InvalidPosition=11): ByteArray
ObjMgrLog Error 4 2005-03-17 14:08:56 (SBL-EAI-04419) Transcode Conversion Failure
CauseThe reason was that the CharSetConversion input argument had been specified .
It invokes transcode on sending data (OK as sending XML) but also on receiving data (not ok as receiving binary data).
Solution
To resolve the behavior, the customer was suggested to call the Transcode Service business service that converted the sending data from UTF-16 to UTF-8 encoding format before calling the EAI HTTP Transport.
With this approach, it was not necessary to set the CharSetConversion input argument when calling the EAI HTTP Transport so that the response message was received successfully by EAI HTTP Transport with a binary data type process property.
Applies to: Product Release: V7 (Enterprise)
Version: 7.5.3 [16157]
Database: Oracle 9i
Application Server OS: Microsoft Windows 2000 Server SP 3
Database Server OS: Microsoft Windows 2000 Server SP 3
This document was previously published as Siebel SR 38-1224854681.
SymptomsSBL-EAI-04419
As part of the upgrade from 6.0.1 to 7.5.3 I need the SAP connector get to work which transfers travel details of expense reports from Siebel to SAP.
The problem is, that the values of several fields are converted incorrectly or are getting corrupted. I will attach the excerpt from a siebel.log file (log level 4 while running Workflow Simulator).
In this log file please notice the following problems:
1. the BAPI integration object fields DEP_TIME and ARR_TIME are translated to RFC column values i.e. from '1980/01/01 08:00:00' to '01/01/1980'
2. fields which are undefined in the integration object i.e. OUT_TIME are getting values in the RFC table: '01/01/1980 Ø :'
3. the fields RKA_TRIP (both 0310 in the integration object) are translated to null and '° Ù '
4. the rfc table column ARR_DATE = '52/ 00:00:00'.
Logging Siebel 6 showed that times were inserted into the RFC tables in the format '1980-01-01 08:00:00' and all other field left empty if undefined or filled with the exact same values.
In the (BAPI) integration object no changes were made. The date and time fields are defined as "Date Type = DTYPE_DATETIME" and "External Data Type = DATS" and "External Data Type = TIMS", length 8 and 6.
What do I need to change in the BAPI integration objects or mapping script to fill the rfc table columns correctly?
Thanks in advance.
SolutionMessage 1For the benefit of other users,
The customer reported unexpected behavior in outbound (from Siebel Application to SAP R/3) BAPI integration process, when mapping Siebel integration component field of type: 'DTYPE_DATETIME' to BAPI integration component field of the external (SAP)-type: 'TIMS' caused:
1. the corrupted time value, populated in the BAPI-field;
2. content of the internal table with field of the SAP-Type: 'TIMS' was shifted.
As result the SAP R/3 Application was not able to complete the BAPI call, because the information in the input parameters was malformed.
A detailed Siebel Application log file contained following processing statements, when a business component field (say: 'Time') of type: 'DTYPE_TIME', which was properly instantiated and mapped as integration component field ('Time') of type: 'DTYPE_DATETIME', but incorrectly passed as field ('TIME') of SAP-type: 'TIMS' to the BAPI call:
"...
EAISiebAdpt EAISiebAdptTrcBusObj 4 ... Get business component field: 'Time', Value: '11:22:33'
...
EAISiebAdpt EAISiebAdptTrcIntObj 4 ... Set integration component field: 'Time', Value: '1980/01/01 11:22:33'
...
EAISAPBAPIAdpt EAISAPBAPIAdptDebug 4 ... TIME = '1980/01/01 .'
...".
Whereas following statement was expected to pass the proper time value ('112233') to the SAP-application:
"...
EAISAPBAPIAdpt EAISAPBAPIAdptDebug 4 ... TIME = '1980/01/01 11:22:33'
...".
Message 2* * *
Following information was provided fro Siebel Technical Support:
As it is stated in the 'Siebel Connector for SAP R/3' Siebel Bookshelf document, chapter: 'Data Types', section: 'Data Fields':
"...
- When a DATS field is sent to SAP, the SAP adapters extract the date portion of the Siebel DTYPE_DATETIME field and construct an 8 character DATS field in the correct format.
- When a TIMS field is sent to SAP, the SAP adapters extract the time portion of the Siebel DTYPE_DATETIME field and construct a 6 character TIMS field in the correct format.
..."
So, the reported incorrect 'DTYPE_DATETIME' -> 'TIMS' types conversion, performed by BAPI Adapter has been reproduced and recognized, as product defect. NOTE: this reverse conversion 'TIMS' -> 'DTYPE_DATETIME' is not affected.
The Change Request 10475441 has been logged to address this case for Siebel Application versions 7.5.x and above. This will be reviewed and considered to be fixed in future release.
Message 3* * *
For affected Siebel Application release, following workaround solution can be considered, to make transparent SAP-field mapping of type 'TIMS' from explicit string expression: 'HHMMSS' (hours 24, minutes and seconds):
1. modify used BAPI input integration component field(s) definition, which have the 'External Data Type' property set to 'TIMS' (SAP-type) to:
1.1 change the 'External Data Type' property from 'TIMS' to 'CHAR';
1.2 change the 'Data Type' property from 'DTYPE_DATETIME' to 'DTYPE_TEXT'.
2. modify accordant inbound map function(s) of used data transformation business service(s), which prepares the content of the inbound BAPI parameter fields
replace the copy-statement like:
"...
oSAPComp.SetCopySource(iSEBLComp)
...
oSAPComp.CopyFieldValue( "TIME", "Time" );
..."
with following ones:
"...
oSAPComp.SetCopySource(iSEBLComp)
...
oSAPComp.SetFieldValue( "TIME" , DTYPE_to_TIMS( iSEBLComp.GetFieldValue( "Time" ) ) );
...".
Message 4Here, the 'DTYPE_to_TIMS' is a type safe conversion function, programmed as below, to parse the incoming 'DTYPE_DATETIME' format ('DD/MM/YYYY HH:MM:SS') into the 'TIMS' formed string ('HHMMSS'):
"...
function DT_to_TIMS( tt )
{
return(( tt != null
&& tt.length == 19
? tt.charAt(11) + tt.charAt(12)
+ tt.charAt(14) + tt.charAt(15)
+ tt.charAt(17) + tt.charAt(18)
: "000000" ));
}
..."
NOTE: No definition changes for corresponding Siebel internal integration component fields are required.
NOTE-2: After application of this workaround the sample detailed Siebel Application log, from above, would contain following traces:
"...
EAISiebAdpt EAISiebAdptTrcBusObj 4 ... Get business component field: 'Time', Value: '11:22:33'
...
EAISiebAdpt EAISiebAdptTrcIntObj 4 ... Set integration component field: 'Time', Value: '1980/01/01 11:22:33'
...
EAISAPBAPIAdpt EAISAPBAPIAdptDebug 4 ... TIME = '112233'
...".
Applies to: Siebel Connector for PeopleSoft Applications - Version: 7.5.3.7 [16190] and later [Release: V7 and later ]
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***
Symptomsthe 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.
CauseWe 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 10480807 for this behavior and fix request 12-OWZYLF for a future Siebel 7.5.3.x maintenance release to contain the fix.
SolutionThe 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.
ReferencesBUG:10480807 - BAPIRECEIVER DOES NOT RETRIEVE CODEPAGE FROM SAP WHEN RECEIVING ENU THEN JPN DATA
 RelatedProducts Siebel > Customer Relationship Management > CRM - Enterprise Edition > Siebel Connector for PeopleSoft Applications Siebel > Customer Relationship Management > CRM - Enterprise Edition > Siebel Connector for SAP R/3 Siebel > Customer Relationship Management > CRM - Enterprise Edition > Siebel Connector for Oracle Applications Keywords | |
UPGRADE TO 7.5.3; SAP; UNICODE; IDOC; TRACE; RFC; CODEPAGE | |
Errors | |
SBL-DAT-00473; SBL-EAI-04419; ERROR 4; ERROR 1 | |
אין תגובות:
הוסף רשומת תגובה