Areas of SAP XI in Detail Area Integration Builder Description Central tool for the design and configuration of the

collaborative process. All the basic functions of the Integration Builder are described in this section. All subareas for design and configuration, and their editors (often graphical) in the Integration Builder, are documented in the subsections for Design andConfiguration (see below). Organization of objects within SAP XI, versioning and transport of these objects.

Software Logistics for XI Objects Design (Integration Repository) Designing Integration Scenarios

Design of the collaborative process at the application component level. In the Integration Builder, integration scenarios are used as the central point for understanding the relationships between the objects involved (interfaces, mappings, integration processes). You also use design at configuration time to map the collaborative process to the current system landscape. Design of executable integration processes. Crosscomponent integration processes support a stateful message processing on the Integration Server. Description and use of messages in interfaces for message exchange. You create interfaces in the Integration Builder and use proxy generation to generate executable proxies in SAP application systems. Furthermore, you can use the Integration Builder to import message schema and SAP interfaces to the Integration Repository for use in the further design process. Design of graphical message mappings and import of Java and XSLT mappings. Description of how to register these mapping programs for the source and target interface.

Designing Integration Processes (ccBPM) Designing Interfaces and Proxy Generation

Designing Mappings

Configuration (Integration Directory) Defining Collaboration Profiles Description of the technical sender and receiver options (and how to identify them) using communication parties, services, and communication channels. Description at a logical level of which service a message is to be sent to. The service can be a business system, an integration process, or a service for a B2B communication. Assignment of a receiver interface to a sender interface. You also register whether mapping programs are to be executed from the Integration Repository for this interface pair, and if so, which mapping programs.

Defining Receiver Determinations

Defining Interface Determinations

Defining Collaboration Agreements

In a collaboration agreement you define which communication channel to use to process messages for a particular combination of senders and receivers. Grouping of all configuration objects by the scenario in which they are required. You can apply integration scenarios from the Integration Repository for a configuration scenario in the Integration Directory.

Defining Configuration Scenarios

Runtime Integration Engine Proxy Runtime Central runtime component of the Integration Server for receiving, processing, and forwarding messages. Runtime component for proxy communication between the Integration Server and application systems based on SAP Web AS. Runtime components that use adapters to connect external systems and R/3 systems to the Integration Server by means of RFC calls. The IDoc adapter and the plain HTTP adapter run independently of the Adapter Engine. Functions for monitoring the involved XI components, the message processing by one or more components, and the performance of message processing.

Adapter Engine

Central Monitoring

Additional Tools (Optional) Tool ARIS for SAP NetWeaver Use Add functions to SAP NetWeaver for graphically modeling processes at various levels. At the highest level (Process Architecture Model), the process architecture of a company is built from a purely business perspective, that is, without technical details. You can find ARIS for SAP NetWeaver in the SAP Software Distribution Center on SAP Service Marketplace at service.sap.com/swdc. Adds functions to SAP NetWeaver for converting data to and from XML. It can process unstructured, semi-structured, and structured data. The Conversion Agent can be called using an adapter module in the Adapter Framework of SAP Exchange Infrastructure. You can find SAP Conversion Agent by Itemfield in the SAP Software Distribution Center on SAP Service Marketplace at service.sap.com/swdc.

SAP Conversion Agent by Itemfield

SOAP Adapter FAQ

Written by Anon.

1. Sender Connection

Q: To which URL can I send my SOAP message?

A: The URL for your SOAP sender channel is http://host:port /XISOAPAdapter/MessageServlet?channel=p:s:c where host is the host name, port is the port number, p is the optional party name, s the service name, and c is the channel name, respectively.

Q: My client gets no connection to the adapter's URL.

A: Make sure that the adapter is running at the specified URL. Use your browser to open the URL for your SOAP sender channel. The page should show a status page with status "OK".

Q: I get an authorization error "401 Unauthorized" from the adapter's servlet. What went wrong?
A: The adapter's servlet is protected by default. You must use one of the user names assigned in security role xi_adapter_soap_message for component XISOAPAdapter. Please consult the documentation for Visual Administrator to view and change the security setting. The user authentication of the SOAP adapter is not part of the SOAP adapter but of the web container of the J2EE engine. The default authentication setting is defined in the web.xml descriptor file of the SOAP dapter web application. This setting may be modified from Visual Administrator with some restriction. Please refer to the security documentation for the J2EE engine.

Q: I get a permission error "403 Forbidden" from the adapter's servlet. What went wrong?
A: It is likely that the URL is incorrect or the adapter is not correctly deployed.

Q: I get a server error "500 Internal Servler Error" from the adapter's servlet. What went wrong?
A: There are several possibilities. It is lilely that the request message arrived at the SOAP adapter but there was some error in the request message or in the channel configuration. In this case, the error message returned should be a SOAP fault message containing the detailed error information. The possible causes can be "No SOAP envelope", "invalid channel", "no receiver agreement", etc. If your SOAP client cannot display this detailed error information, please capture the message using some tool (See question "How can I trace the whole message?").

Q: I get the invalid channel error even though I have configured the corresponding channel in the directory.
A: To check if the channel is available, you can open the following URL from your browser. http://host:port /XISOAPAdapter/HelperServlet?action=FindChannel& channel=p:s:c where host is the host name, port is the port number, p is the optional party name, s the service name, and c is the channel name, respectively. This will show a page with the channel information if the channel is available. If the channel is not available, please make sure that your channel name is correct and the adapter engine's CPA cache is valid.

Q: Can I use SSL for my sender adapter?

A: Yes. Normally, the SOAP adapter servlet runs on the engines HTTP port. But you can activate the engine's HTTPS port so that this servlet can receive messages sent to the HTTPS port. See the documentation about the J2EE engine's security configuration.

Q: My SOAP client gets a SOAP fault that indicates timeout in calling the adapter engine. Can I increase the
default timeout value? A: Yes. The default timeout value for synchronous calls is 5 minutes. You can increase this value by setting parameter XI.Timeout in the module parameter table of the SOAP adapter. The value must be given in milliseconds. For example, value 600000 represents the timeout value of 10 minutes. This parameter is not recognized in systems prior to SP13. 2. Sender Asynchronous Calls

Q: What are the correct sender options for asynchronous calls?

A: The setting in the channel configuration determines how the message is passed to the XI infrastructure. Setting the channel's quality of service to ExactlyOnce guarantees the delivery of the message exactly once between the adapter and the back end. This will not automatically guarantee the delivery with exactly once between the client and the back end. The behavior of the client determines the level of quality of service achieved. When the client sends a SOAP message and ignores the response completely as in "fire-and-forget", the quality of service with AtMostOnce may be realized. When the client sends a SOAP message and checks if the response is an HTTP 200 response message, the quality of service with AtLeastOnce can be realized. In this case, the client must resend the message until such a successful response is returned. When the message successfully accepted by the adapter, an HTTP 200 response with an empty SOAP envelope is returned. When the client resends the message, there is a possibility that the message may arrive more than once. However, this possible duplicate only happens, when the client previously received no response message at all or an HTTP 500 with duplicate message ID error. For all other cases, the client can resend the message without resulting any duplicate. In order to eliminate duplicates for all cases, the client may send the message with a unique message ID. This message ID will be used to create an XI message so that the identity of the created XI message and that of the original SOAP message are coupled. The client must resend the message with the same message ID until an HTTP 200 reponse is returned or an HTTP 500 response with SOAP fault DuplicateMessageException. In either case, the client can assume that the message is delivered exactly once (theoretically the message ID could be identical to another message ID used previously but the probability of this is extremely low). Related Questions "How to set the message ID from SOAP client?"

Q: How to set the message ID from my SOAP client?

A: You can set the message ID in the request URL as http://host:port /XISOAPAdapter/MessageServlet?channel=p:s:c& version=3.0&...&MessageId=xxxxxxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx where xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx is a GUID string. Related Questions "What are the options for asynchronous calls?"

Q: How to set the queue ID from my SOAP client?

A: You can set the message ID in the request URL as http://host:port /XISOAPAdapter/MessageServlet?channel=p:s:c& version=3.0&...&QueueId=xxxxxxxxxxxxxxxx where xxxxxxxxxxxxxxxx is an ABAP queue ID. Related Questions "What are the options for asynchronous calls?" 3. Other Sender related Questions

 Q: My SOAP client throws an error. What can I do?

A: You need to find out what exaclty this error is. It could be a connection error, authorization error, parsing error, etc. If your client itself does not provide detailed information, you need to set up a TCP gateway between your client and the sender adapter. See question "How can I trace the whole message?".

Q: Where can I see messages I sent from my soap client?

A: The adapter's message monitoring tool should display all the messages that entered the adapter engine. Those messages that arrived at the SOAP adapter but resulted in some error are shown in the error message box of the message monitor. Finally, those messages that didn't even reach the SOAP adapter will not be displayed anywhere. If you don't see your messages in the monitor, you should inspect the response message that your client received. The response message should contain information about the cause of the error. Related Questions "How can I trace the whole message?"

Q: What character encoding is supported by the SOAP sender adapter?

A: The SOAP sender adapter can accept any character encoding supported by the local JDK. When you are using a particular character encoding with content type text/xml, you must make sure that the encoding name given in the content type and in the XML declaration must be consistent. What makes this more complex is that the default values. The default encoding for "text/xml" is US-ASCII, whereas the default encoding for the XML declaration is UTF-8 or UTF-16. The following examples show several valid combinations of content-type and XML declartion: text/xml <?xml version='1.0' encoding='us-ascii'?> text/xml; charset='utf-8' <?xml version='1.0' encoding='utf-8'?> text/xml; charset='utf-8' no declaration text/xml; charset='iso-8859-1' <?xml version='1.0' encoding='iso-8859-1'?> application/xml <?xml version='1.0' encoding='iso-8859-1'?> The response message from the SOAP sender is normally encoded in UTF-8. If you want to change this encoding, for instance to iso-8859-1, you can set parameter XMBWS.XMLEncoding to iso-8859-1 in the module configuration for the SOAP adapter module. Related Questions "What character encoding is supported by the SOAP receiver adapter?"

Q: My sender adapter gets a timeout error from the adapter engine. What is the default timeout value and
can I change it? A: The default timeout value for a synchronous call to the adapter engine is 5 mintues. From SP13, you can change this value by setting parameter XI.Timeout in the module configuration table. This value must be set in milliseconds (e.g., 300000 for 5 minutes). 5. Receiver Connection

Q: Can I use SSL for my receiver adapter?

A: Yes. You can enter any target URL with "https:..." and the adapter will use the HTTP protocol over an SSL connection.

Q: I get the SSL handshaking error. I get some error when I call my SSL web service.

A: First, please make sure that the SSL server is working correctly with another client. If the server is working and you still have the problem, the most likely cause is that your J2EE engine is not configured appropriately to be able to use the unrestricted strong features of the cryptographic library. Please make sure that: - The JDK java security lib directory ($JAVAHOME/jre/lib/security) contains the unrestricted strong version of local_policy.jar and US_export_policy.jar, which are about 5KB and not the restricted version that are about 3KB each. If you have the restricted version, please refer to http://java.sun.com/ to obtain the unrestricted version. - The full version of IAIK is available in the J2EE engine's Security Provider. To check this, go to Service -> Security Provider -> Cryptography Providers, and select IAIK. The Provider Information field should show the full version (e.g., IAIK Security Provider v3.12) and not the evaludation version (e.g., IAIK Security Provider v3.01, evaluation version). If you have the evaludation version, please refer to the security setting section of the SAP J2EE documentation.

Q: Can I use SSL with client certificate to authenticate my adapter?

A: Yes. You can configure your receiver channel to use a client certificate. This feature is available from SP13.

Q: I cannot call an SSL web service requiring a client certificate.

A: If you can call an SSL web service requiring no client certificate, please make sure that your clietn certificate is valid and correctly stored in the key store of the J2EE engine. There have been some problems reported in SP13. Please consult SAP Note 870845 for the correction and/or the workaround.

Q: Can I use several HTTP proxy servers for my channels?

A: Yes. You can configure your proxy setting per channel. 6. Receiver Asynchronous Calls

Q: What are the correct receiver options for asynchronous calls?

A: The processing mode of the receiver is determined by the message that reaches the receiver. If you are sending a message with some quality of service, to provide this service of quality to the server, your must make sure two things. First, your receiver channel must be configured to pass the XI message ID to the server. Second, your web service must check duplicates using this message ID.

Q: What should my web service return to the adapter for asynchronous calls?
A: Currently, the receiver adapter expects an HTTP 200 with a SOAP envelope with an empty content for successful delivery. Any other response will result in a XI system error and triggers retries of the message. When you want to check duplicates, you should configure your receiver channel to pass the XI message header information to the server. Prior to SP11, a SOAP fault resulted in the application or system error, depending on whether the SOAP fault contained a detail child element or not. This behavior contradicted the communication model. Therefore, it has been changed so that the adapter generates the system error for any SOAP fault in asynchronous calls. When you want to check duplicates in your web service, you should configure your receiver channel to pass the XI message header information to the server. When your web service indeed find a duplicate, assuming that the previous message was simply lost, your web service should return an HTTP 200 with an empty SOAP envelope. 7. Other Receiver related Questions

Q: What should my web service return to the adapter?

A: The receiver adapter expects a SOAP message as response. For synchrnous calls, a successful response should be returned with HTTP 200. In this case, the content of the SOAP body will be returned to the caller as the response payload. When some error occurs, the SOAP message may contain the SOAP fault element. In this case, when the

fault detail element is not empty, its content will be returned as the fault payload in an application error message. For others, a system error message will be returned to the caller. HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>34.5</Price> </m:GetLastTradePriceResponse> </SOAP:Body> </SOAP:Envelope> will result in an application response message with response payload <m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>34.5</Price> </m:GetLastTradePriceResponse> HTTP/1.1 500 Internal Server Error Content-Type: text/xml; charset="utf-8" <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <SOAP:Fault> <faultcode>SOAP:MustUnderstand</faultcode> <faultstring>SOAP Must Understand Error</faultstring> </SOAP:Fault> </SOAP:Body> </SOAP:Envelope> will result in a system error message. HTTP/1.1 500 Internal Server Error Content-Type: text/xml; charset="utf-8" <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <SOAP:Fault> <faultcode>SOAP:Server</faultcode> <faultstring>Server Error</faultstring> <detail> <e:myfaultdetails xmlns:e="Some-URI"> <message>My application didn't work</message> <errorcode>1001</errorcode> </e:myfaultdetails> </detail> </SOAP:Fault> </SOAP:Body> </SOAP:Envelope> will result in an application error message with fault payload

<e:myfaultdetails xmlns:e="Some-URI"> <message>My application didn't work</message> <errorcode>1001</errorcode> </e:myfaultdetails> For asynchronous calls, see "What should my web service return to the adapter for asynchronous calls?".

Q: My receiver adapter received an HTML page instead of a SOAP XML. What happened?
A: See question "My receiver adapter received something other than the SOAP envelope".

Q: My receiver adapter received something other than the SOAP envelope. What happened?
A: The most likely cause is the wrong target URL or invalid authorization given in the channel configuration. Please make sure that these values are correct. If the problem persists, you need to trace the transported messages. See question "How can I trace the whole message?".

Q: Where can I see messages I want to send to my web service?

A: The adapter's message monitoring tool should display all the messages that go through the adapter engine. When your scenario is configured correctly, your message should be displayed in the message monitor. If there is no error for your message, the adapter has successfully send your message to your web service. Related Questions "How can I trace the whole message?"

Q: What character encoding is supported by the SOAP receiver adapter?

A: The SOAP receiver adapter can use any character encoding supported by the local JDK. The request message from the SOAP receiver is normally encoded in UTF-8. If you want to change this encoding, for instance to iso-88591, you can set parameter XMBWS.XMLEncoding to iso-8859-1 in the module configuration for the SOAP adapter module. This setting is for the outgoing SOAP message and has no effect on the incoming SOAP message. For the incoming SOAP message, any code page supported by the local JDK is accepted. Related Questions "What character encoding is supported by the SOAP sender adapter?"

Q: My web service returns a SOAP with multiple elements in the SOAP body but I can see only the first
element in the XI main payload. How can I get all the elements into the XI message? A: The default behavior of the SOAP adapter is to place the first element of the SOAP body into the XI application payload. If the SOAP message contains more than one elements in its SOAP body, you can configure the channel to run in the noSOAP mode. In this mode, the XI application payload of the request message is directly sent to the web service and its response is returned in the XI application payload of the response message. You must make sure that the XI appliaction payload passed to the SOAP receiver adapter represents a SOAP request message accepted by the web service. The SOAP receiver adapter returns the response message containing the SOAP response message in its XI application payload. If your original XI application payload is not represented as a SOAP message, you need a mapping to map your XI payload between its original format and its SOAP format. 8. Other Questions

Q: My sender adapter is still not working. What can I do?

A: Please open a problem report, describe the problem, and provide the necessary information. See question "Which information must be included in a problem report?".

Q: My receiver adapter is still not working. What can I do?

A: Please open a problem report and provide the information given in the answer to question "Which information must be included in a problem report?".

Q: Does the RPC or Document style in WSDL play a role in the SOAP adapter?
A: No. These styles are used in WSDL to describe how the message is represented as a SOAP message. And this corresponds to how the XI payload is represented. You must make sure that your XI proxy is generating the valid payload according to the given WSDL in whatever the style. If this is not the case (e.g., your proxy is generated by another WSDL and there is a mismatch in how the payload must look), you need to configure some mapping to match the payload. Related Questions "Can I convert an RPC styled WSDL to a document styled WSDL?"

Q: Can I convert an RPC styled WSDL to a document styled WSDL?

A: It is difficult to answer yes or no because the answer depends on the WSDL instance and the implementation of the code that binds the XML instance to some native object. The problem comes from the fact that these two styles describe web services in different layers. The document style WSDL describes how one can bind an XML document to the SOAP message format. In contrast, the RPC style WSDL describes how one can bind an object to the SOAP message format. One can imagine that this works in two steps: first representing the object as an XML document and then binding this XML document to the SOAP message format. How this first step works is controlled by the SOAP encoding name. For the standard encoding specified in the SOAP specification, most objects can be easily described in an equivalent XML schema. Some special objects such as references and arrays must be represented by some special rules and some additional meta information in XML. This implies that these additional attributes and elements must also be described in the XML schema and the document style based proxy must set these values in the instance appropriately. One must however note that even if one has an equivalent document style WSDL, this does not automatically guarantees the interoperability. Some RPC styled service implementations have significant interoperability problems such as requiring the xsi:type attribute for every element or the SOAP encoding attribute at some particular element. If one has to call such non conformant SOAP service, one must adjust the message accordingly. Attachment wsdl_style_samples. zip contains some examples of WSDL documents and sample SOAP messages that illustrate how one can write an equivalent WSDL in another style. Related Questions "Does the RPC or Document style in WSDL play a role in the SOAP adapter?"

Q: Which information must be included in a problem report?

A: Please refer to Note 854536 for the information necessary for adapter problems.

Q: How can I trace the whole message?

A: If you have a third-party web service server or client and if it works with their own test tool but not with the SOAP adapter, you need to analyze the messages that are transported. Typically, this is done by either inseting a TCP gateway between the client and the server or non-invasively using some packet catching utility. You are free to use any tool but make sure that the tool can capture the messages as raw bytes. Some tools are known to store the captured messages as text and corrupt some characters. You can find a tool called TCPGateway in the attachment section of this note (stored in tcpgw.zip). Please unpack this zip file and open index.htm for more details.

Q: Which information must be included in a problem report?

A: The following information must be included: For receiver problems:

o Screenshots of the SOAP channel configuration.

o The audit log information from the failing message's audit log. o The SOAP message that the adapter is sending to the web service. o The SOAP message that is known to work for the web service. o The WSDL file for the web service if available. o The vendor information of the web service.

For sender problems:

o Screenshots of the SOAP channel configuration. o The audit log information from the failing message's audit log or the error log for non-persisted
messages.

o The SOAP message that the client is sending to the adapter. o The response message that the client is receiving from the adapter. o The vendor information of the client.

Last Updated (Saturday, 08 August 2009 11:15)

Mail Adapter FAQ

Written by Anon.

1. Sender Connection

Q: My mail messages seem to be read by the adapter but not processed. At least there is no message
shown in the message monitor.

A: Please look at the adapter monitor in Runtime Workbench. You should be able to find your mail sender channel under the Mail adapter. The detail text of the channel should describe the problem. 2. Sender with XIALL

Q: I get some exception and my mail message does not seem to be processed.
A: Please check the status of your channel in the adapter monitor. The status of the adapter monitor is updated for each polling cycle. Therefore, you should look at the status right after a new message is picked up by your channel. From this status message, you should be able to find out if the problem is due to some communication problem with the mail server or to some mail format problem. 3. Sender with XIPAYLOAD

Q: How can I get the original sender email address and subject, etc?

A: You need to use the mail package option to get mail transport specific information in the XI payload. In SP14, there will be a new mechanism to transport transport specific information for all adapters. 4. Sender Asynchronous Calls

Q: What is offered by a sender channel configured as ExactlyOnce or ExactlyOnceInOrder?

A: The quality of service setting in the sender channel does not mean that this quality of service is automatically provided between the mail server and the XI system. The setting only allows the adapter to be able to call some XI asynchronous receiver and the specified quality of service is provided between the adapter engine and the receiving component. If some error occurs 5. Other Sender related Questions

Q: My mail messages are not picked up.

A: The mail sender channel with IMAP4 fetches only the unread messages from the specified mail box in the order they are stored. Therefore, please make sure that you have some unread messages in the top of the list (if ordered by most recent on top). After a polling cycle, you can look at the status of this channel at the adapter's monitor. This should show any error if the messages are not processed correctly. Once the messages are read but not processed correctly, they remain in the mail box but are not read in the subsequent polling cycle. You must correct the problem and delete these messages using your mail client program or reset them as unread so that they can be resend. The channel with POP3 fetches all messages from the specified mail box in the order they are stored. After a polling cycle, you can look at the status of this channel at the adapter's monitor. This should show any error if the messages are not processed correctly. Once the messages are read but not processed correctly, they remain in the mail box and read again in the subsequent polling cycle. If the problem is permanent, you must correct the problem or delete these messages using your mail client program. 6. Receiver Connection

Q: My mail messages does not seem to be sent out.

A: Please look at the adapter monitor in Runtime Workbench. You should be able to find your mail receiver channel under the Mail adapter. If this status is OK. Please look into the message monitor and find the audit log entries for this message. The detail text of the audit log should describe the problem. 7. Receiver Asynchronous Calls

Q: Is it guaranteed that an XI message with quality of service ExactlyOnce will result in one mail message to
be sent?

A: No. Most mail gateways do not support quality of service. Therefore, the adapter simply sends the message. If some error occurs, the message is resent. 8. Other Receiver related Questions

Q: Some characters such as ,, are corrupted in my mail. How can I preserve these characters?
A: First, please make sure that the payload passed to the mail adapter contains the correct characters. When XIALL or XIPAYLOAD without the mail package is used, the mail message sent out from the mail adapter represents each payload of the original XI message passed to the mail adapter. Therefore, you can analyze the problem by capturing the mail message sent out form the mail adapter. When XIPAYLOAD with the mail package is used, the mail message is created from the mail package payload of the XI message. Therefore, you must temporarily change the mode to either of the other two and capture the mail message. To capture the mail message, you can use TCPGateway described in Question "Can I monitor what my mail adapter sends or receives from the mail server?" to capture the mail message. This tool can be placed between the mail adapter and the mail server to capture the messages. The captured messages can be saved in a file. Please see the included documentation for this tool for more details.

The reason for the corrupted characters is most likely caused by the corrupted original payload or the incorrect character code setting in the payload. By analyzing the captured message, the cause of this problem can be identified.

Q: Can I choose the name of an attachment in the mail?

A: Yes. Most mail clients use some heuristics based on some MIME headers to derive the name of an attachment. The MIME headers involved in most heuristics are Content-Type, Content-Description, and Content-Disposition. When you create an XI message, the XI payload name is automatically set in the Content-Description. If you want to change or set all of these headers, you can use the MessageTransformBean module (Note 793922) in the adapter framework. 9. Other Questions

Q: Which URL do I need to specify for some IMAP4 folder?

A: You can specify your folder as URL. For example, if your server is called host and your folder is called MyInBox which is in another folder called path, your URL should look like imap://host/path/MyInBox If your server runs on another port than the default IMAP4 port (143), your URL can be written as imap://host:port/path/MyInBox where port is the port number

Q: Which URL do I need to specify for some POP3 folder?

A: You can specify your POP3 server as URL. For example, if your server is called host, your URL should look like pop://host/ If your server runs on another port than the default POP3 port (110), your URL can be written as pop://host:port/ where port is the port number

Q: How can I configure my sender channel for my SMTP server?

A: You can specify your SMTP server as URL. For example, if your server is called host, your URL should look like smtp://host/ If your server runs on another port than the default SMTP port (25), your URL can be written as smtp://host:port/ where port is the port number

Q: Which user authentication mechanism is supported by the sender adapter?

A: The plain authentication and the CRAM-MD5 based authentication are supported(CRAM-MD5 support from SP11). The client certificate based authentication is not supported.

Q: Can I use SSL for the connection to my mail server?

A: Yes. You can use URL imaps://... for IMAP4 over SSL, pops://... for POP3 over SSL, and smtps://... for SMTP over SSL. If the ports differ from the respective default ports (993, 995, 465, respectively), they should be given in the URL.

Q: My sender adapter is still not working. What can I do?

A: Please open a problem report, describe the problem, and provide the necessary information. See question "Which information must be included in a problem report?".

Q: What is the purpose of the XIALL mode?

A: This mode allows the transport of an XI message over some mail gateways. You can configure a mail rerceiver adapter at one XI system and a mail sender adapter at another XI system to transport XI messages between these two systems. All the information contained in the original XI message at the first system is reconstructed at the second system.

Q: What is the purpose of the XIPAYLOAD mode with MailPackage?

A: The mail package format (Mail) allows some of the mail transport specific information to be included in the XI payload. For specific usage, please refer to "How to use MailPackage in Sender?" and "How to use MailPackage in Receiver?".

Q: My receiver adapter is still not working. What can I do?

A: Please open a problem report and provide the information given in the answer to question "Which information must be included in a problem report?".

Q: Can I monitor what my mail adapter sends or receives from the mail server?
A: The mail protocols such as IMAP4, POP3, and SMTP are TCP based protocols. You can configure any TCP gateway or monitor tool to capture the data. You can find a tool called TCPGateway in the attachment section of the SOAP Adapter FAQ note 856597. Please see tcpgw.zip for more details.

Q: Which information must be included in a problem report?

A: The following information must be included:

o Description (participating components and concrete problem) o Adapter Version SP and patch numbers of SAPXIAFC and SAPXIAF o For receiver problems

The channel setting The message entry from the adapter's message monitor in Runtime Workbench. The XI message that is passed to the adapter The mail message that is posted to the mail server if available The vendor information of the mail server

o For sender problems

The channel setting The message entry from the adapters' message monitor or from the error message folder in Runtime Workbench The mail message that is fetched by the adapter

The XI message that is passed to the adapter engine if available The vendor information of the mail server

Last Updated (Saturday, 08 August 2009 11:16)

1:N IDOC Receiver Without BPM. Yes Its Possible!

JUNE 9, 2009 BY CRAIG STASILA 1 COMMENT

For those of you familiar with PI, you know that it likes to deal with single messages, and not multiple messages in bulk. Many interfaces to legacy systems require single file interfaces. If you are using a file sender adapter and an IDOC receiver adapter, I have a little tip for you that will allow you to process one file into many IDOCs. At a client of mine, I had to develop an interface to accept a file with IDOC acknowledgments. Our SAP system was sending data to an external system and the external system was sending back status messages that we were to post using ALEAUD. The status file was written periodically and could contain any number of records. Each record needed to be its own IDOC. The problem is that there is no out of the box solution that allows 1:N fil e to IDOC mapping. I searched a bit on SDN and found that there were others with my same problem. All of the responses, however, suggested using BPM. That just didnt s eem right to me. BPMs are great and all, but I dont feel like I should need to implement a BPM to do something as simple as 1:N correlations. I set out to find a better way to do 1:N correlations with IDOCs and found that is actually was real easy.

After doing my research, I found that the issue is not with the IDOC adapter nor mapping engine, but rather the issue lies in the meta-data imported from the ECC instance. The meta-data describing the IDOCs has an element occurs of 1..1i.e. each message that contains an IDOC can contain one and only one IDOC. As it turns out, SAP handles the case if multiple IDOCs are passed to the receiver IDOC adapter. The mapping engine can easily handle multiple IDOC occurrence. The only limitation is the IDOC meta-data and, as I will show you below, that is an easy limitation to overcome. 1. First, in your XI integration repository, download the IDOC definition from your ECC/R/3 instance as you normally would for any standard IDOC integration

scenario.

2.

Complete the message mapping and the rest of the integration scenario development as usual.

Notice how the source message has an occurrence of 1..unbounded, but destination message is limited to an occurrence of 1..1. If the mapping were to remain this way, no matter how many IDOC tags would be in the source XML, one and only one IDOC tag will be created in the resultant XML. Well take care of this next.

3. 4.

Export the XSD for the IDOC to a file on your PC. Open the file in a text editor and change the element named IDOC. Add the following text:minOccurs="1"

maxOccurs="unbounded"

Save and close the XSD file.

5.

In the message mapping created in step 2, import the XSD created in the previous step as the message reference for the IDOC. Notice how the evil 1..1 occurrence constraint on the IDOC tag is now 1..unbounded!

6.

Multiple rows in the file will create multiple IDOCs! Are you as excited as I am? So, what did we learn today? You arent completely locked into the meta-data derived by SAP. The reciver IDOC adapter is pretty forgiving (much more so than the sender IDOC adaptermore on that another day) Most importantly, it is possible for a 1:N multi-message IDOC reciver