I have a problem with sending RFC from R/3 to XI

This weblog is a response to a few question about the basic configuration of the RFC sender adapter
that were posted on the XI forum (and also on my e-mail) :)

So here we go, basically we have to configure 2 things:

a) RFC destination

b) RFC channel in the XI directory

RFC destination:

1. To create the RFC go to TCODE: SM59

2. Create new destination of type T (TCP/IP)

3. Make sure you select Registered Server Program option before writing your program ID

4. Write you program ID (remember it's case-sensitive)

5. In the gateway host and gateway service write the values of your "Application system" - business system (not the XI server)



7. No configuration in the J2EE administrator nessecary

Now we can proceed to RFC channel configuration:

1. Enter your Application Server

2. Your Application Server Service

3. Enter your Program ID from the RFC destination



And we're done:)
Now you can test the RFC destination in SM59 to see if it works.

How do I use 'Apply Control Record Values from Payload' parameter with the IDOC adapter?

See notes:
a) 728792 - how the fields in the control record get set.
b) 792333 for an overview of how to convert partners in the IDoc adapter.

Also check:

Fields of the IDoc Control Record

The following table provides information about how the fields of the control record are filled by the receiver IDoc adapter.

Field Name	Value
TABNAM	Constant EDI_DC40, if version = 3 Constant EDI_DC, if version = 2
SNDPOR	Constant SAP+SYSID of the Integration Server
MANDT	Integration Server client
DOCNUM	Consecutive number from the IDoc number range EDIDOC/01. For reasons of uniqueness, it cannot be taken from the payload.
DOCREL	Integration Server release This is not the release from the communication channel or the receiver system release.
RCVPOR	Determined from port in the receiver IDoc adapter.
ARCKEY	Message GUID for revision
SERIAL	Determined from the control record of the IDOC XML payload.
MESTYP	From the XI interface
IDOCTYP	From the XI interface
CIMTYP	From the XI interface

Partner conversion takes place in the Integration Directory.

Logical systems for SAP systems can also be specified in the System Landscape Directory. B2B partners can be converted by using XI parties.

See also:

· Communication Party Identifiers

· Header Mapping in Receiver Agreement

· Determination of the IDoc partner type in the communication channel, on the Identifiers tab page

The values for the following fields are filled by the configuration in the Integration Directory.

· SNDPRN

· SNDPRT

· SNDPFC

· RCVPRN

· RCVPRT

· RCVPFC

If you have not set the Apply Control Record Values from Payload indicator in the receiver IDoc adapter, the fields are filled as follows:

Field Name	Value
SNDPRN	From XI sender service, configuration in Integration Directory, System Landscape Directory
SNDPRT	Constant LS
SNDPFC	Initial
RCVPRN	From XI receiver service, configuration in Integration Directory, System Landscape Directory
RCVPRT	Constant LS
RCVPRT	Initial
STATUS	Constant 03
DIRECT	Constant 1
OUTMOD	Constant 2
CREDAT	Date created
CRETIM	Time created

The remaining fields that are not shown here are empty. Fields that have the value initial are empty in the control record.

If you have set the Apply Control Record Values from Payload indicator in the receiver IDoc adapter, the following fields are filled from the IDoc-XML payload:

· MESCOD

· MESCFT

· TEST

· EXPRSS

· STD

· STDVRS

· STDMES

· SNDSAD

· SNDLAD

· RCVSAD

· RCVLAD

· REFINT

· REFGRP

· REFMES

· STATUS

· DIRECT

· OUTMOD

· CREDAT

· CRETIM

You can change the contents of the fields by using a mapping.

XI: IDOC Adapter - EDI_DC40 - demystified

When you start working with IDOCs scenarios the first thing you'll probably notice
is the IDOC receiver channel configuration and maybe the lack of sender IDOC adapter:-)

There's one little checkbox you can set or not: "Apply control record values".
When you check standard documentation you may be little confused
but I hope to clear all things out with this weblog.

Scenario 1

We don't set the checkbox.



Since we do not want to fill the control record ourself we can Disable the EDI_DC40 segment.



Now the control record will be filled with those parameters:

TABNAM, SNDPOR, MANDT, DOCNUM, DOCREL, RCVPOR, ARCKEY, SERIAL, MESTYP, IDOCTYP, CIMTYP
SNDPRN, SNDPRT, SNDPFC, RCVPRN, RCVPRT, RCVPRT, STATUS, DIRECT OUTMOD, CREDAT, CRETIM

and they will have values like described on help.sap.com
(so basically nothing difficult over here).

Scenario 2

We set the checkbox.



If you read the documentation you may see this:

"If you have not set the Apply Control Record Values from Payload indicator
in the receiver IDoc adapter, the fields are filled as follows...."

but this is only half of the truth:) Because if you mark the checkbox you're also not able to fill those fields.

If you want to check how this works take a look the little example below.

As you can see I'm sending my IDOC to the IDOC adapter and I'm setting values
like SNDPRT, RCVPRN and also some other like MESTYP.



But the IDOC adapter changes them and uses the standard values as when you don't set that checkbox.





That means that the only values you're allowed to change are those:

MESCOD, MESCFT, TEST, EXPRSS, STD, STDVRS, STDMES, SNDSAD, SNDLAD, RCVSAD, RCVLAD, REFINT, REFGRP

as you can see from the example the IDOC Message Code (MESCOD) is created correctly (just like it was set in my mapping).

This is a very easy scenario but I hope it may be useful for IDOC adapter begginers.

I can't see my adapters in the adater monitoring after the import of a new SP

a) try reimporting "SAP Basis software component"

b) take a look at the XI installation guide on how to do it: "Importing the XI Content for Software Component Version SAP Basis 6.40"

Where can I find J2SE plain Adapter

https://websmp106.sap-ag.de/swdc

Then this path:

- Support Packages and Patches
- - SAP NetWeaver
- - - SAP NETWEAVER
- - - - SAP NETWEAVER 04
- - - - Entry by Component
- - - - - XI Adapter Engine J2SE
- - - - - - XI CONNECTIVITY SE 3.0
- - - - - - - OS independent

How can I access filename from File/FTP Sender Adapter

Finally (from SP14) we can receive a file do something with it inside XI
and send it back with the same name. No need for writing adapter modules,
no need for variable substitution - SAP gave us a new, easy solution to this issue.
From XI 3.0 SP14 we can use Adapter Specific Message Properties.
Now not only can we use the filename of the received file but we can also change it
inside our mapping (using graphical mapping for example).

Let's see how the scenario works:

Step 1

Inside your file/FTP adapter we can now set "Adapter Specific Message Properties"
which tell the adapter to include those properties inside the SOAP message sent to XI
from the adapter. Because we want to see the whole example we can start by setting all of them.



Step 2

The file/FTP receiver adapter must also know that he has to use those new properties
so we also have to set them on the receiver's side.



Step 3

Because we also want to get the filename inside our mapping we have to create a user defined function
which will return the filename and map it to one of our XML tags.

DynamicConfiguration conf = (DynamicConfiguration) container.getTransformationParameters().get(StreamTransformationConstants.DYNAMIC_CONFIGURATION); DynamicConfigurationKey key = DynamicConfigurationKey.create("http://sap.com/xi/XI/System/File","FileName"); String ourSourceFileName = conf.get(key); return ourSourceFileName;

The code shown above just takes the filename so we can map it, if you'd like to change it
have a look at the code provided by SAP: Accessing Adapter-Specific Properties

When we run our file to file scenario we can now see that there's a new section called DynamicConfiguration....



...which is being populated with some values.



When we take a look at our outbound message we can see that one of our tags has the filename value.



Later on we can check our FTP folder to find out that the created file has exacly the same name
as the file from the sender adapter.



Easy wasn't it? This example just shows that SAP listens to us (developers)
to make our lives a little bit easier :)

Where can I find FAQ on adapters?

Take a look at this note:
821268 - XI 3.0 Adapter Framework: Overview of available FAQ notes
inside you'll find all available FAQ SAP notes.

How can I access adapter monitor?

Try this link:
http://xiserver:j2eeport/mdt/amtServlet

Testing Sample Adapter

There are many cases where the existing adapter doesn't meet all your requirements and you want to develop a new adapter. But where to start?

SAP provides a Sample Adapter for this purpose. You can start testing this adapter, understand the code and do modifications.

Deploy

The Sample Adapter is present on the adapter engine with the name sample_ra.sda.You can search for it on your XI Server or on decentralized adapter engine (if u have)

Extract the sample_ra.sda with WinZip. You will get sample_ra.rar and some .xml files(Deployment descriptors).

Extract the sample_ra.rar with WinZip and you can find the sample_ra.jar and .xml files.

To get the Java Doc and source text of sample adapter extract the sample_ra.jar file.

If the sample adapter is already deployed then no need to deploy it again. If it is not deployed then deploy the sample_ra.sda file though SDM.The JNDI name of your deployed adapter will be "deployedAdapters//shareable/. Here the connector name means the name of your .rar file.By default it is deployed. So now all that you need to do for testing Sample Adapter is create the Adapter Meta Data and use the Adapter in Communication channel at configuration time.

Design

Create Adapter Meta Data in Integration Repository. The Meta data should be under the Namespace http://sap.com/xi/XI/sample, with the name JCA and the software component could be anything (it doesn’t matter). This restriction is because; in the ra.xml (extract the sample_ra.rar) file these deployment descriptors were given. If u wants to create Adapter Meta Data with some other name and namespace then change the corresponding values in ra.xml file and deploy it. To create the Adapter Meta Data copy the contents of SampleRa.xml (Extract the sample_ra.jar file) file and paste it in Adapter Meta Data Source Document View (4th icon on create Adapter metadata screen). Once you active the Meta Data Object, then it is ready to be used in Integration Directory at configuration time.

Configuration

At configuration time in communication channel, select the Adapter(the Adapter name is same as Metadata name)that is displayed with the name that u have given for Metadata at Design time. You can use this adapter both on Sender and Receiver side.

Monitoring

You can see the status of Sample Adapter in Runtime workbench same as other adapters

Dynamic Configuration of Some Communication Channel Parameters using Message Mapping

With XI 3.0 SP14, some paramters in the Integration Directory's Communication Channel can be dynamically determined during runtime. A couple of examples are the filename and directory used by the File Receiver Adapter. The values for filename and directory can be obtained from the payload of the XML message.

Now, with XI 3.0 SP16, these values plus many additional ones can also be dyanmically configured using mapping programs, e.g. Message Mapping. In addition, many of these parameters are not available for dynamic configuration by using the Communication Channel as you can do with filename and directory.

For example, for an HTTP Receiver Adapter, the URL can be dynamically assigned with Message Mapping. In addition, the HTTP Header fields can also be assigned within Message Mapping.

Another benefit of using Message Mapping is that the value to be assigned does not have to be in the payload of the XML message, as what the File Receiver Communication Channel configuration requires in the case of filename and directory.

How do we determine which parameters can be assigned with a mapping program? Well, they will be listed in each of the Communication Channel configuration section, "Adapter-Speocific Message Attributes". Once the option, "Use Adapter-Speocific Message Attributes", is checked, all the values will be displayed.

For the discussion here, we will use the HTTP Receiver Adapter as an example. We will assign a value to the HTTP header, DOCTYPE, using Message Mapping.

Here are the steps:

1. Configure the HTTP Receiver Communication Channel.

   In the section, "Adapter-Speocific Message Attributes", check the options: "Use Adapter-Speocific Message Attributes" and "Apply HTTP Header Fields". Enter "DOCTYPE" in "Field 1". This will be the HTTP header name.

   

2. Create a user-function in Message Mapping:

   

   The source code is below:

   DynamicConfiguration conf = (DynamicConfiguration) container.getTransformationParameters().get(StreamTransformationConstants.DYNAMIC_CONFIGURATION); DynamicConfigurationKey keyHeader1 = DynamicConfigurationKey.create( "http://sap.com/xi/XI/System/HTTP", "HeaderFieldOne"); conf.put(keyHeader1, a); return "";

   (Please note "HeaderFieldOne" is the technical name for "Field 1" in the Communication Channel configuration. The namespace used is also specific to the adapter. Please reference help.sap.com for the namespace and technical names.)

3. Use the user-function in Message Mapping:

   

   In the mapping, the value of the element "type" from the source will be assigned to the HTTP header "DOCTYPE".

   The reason the target of the mapping is the root element is because we do not want to map this to any element, so a "" containing nothing is assigned to the root of the target.

   Incidently, the "Test" tab in Message Mapping cannot be used to test the user-function. You will get a "NULL Pointer" exception. However, you can test it using the "Test" tab in Interface Mapping.

Using the following source XML:

<?xml version="1.0" encoding="UTF-8"?> <source_file_mt> <type>SalesOrder</type> <record><br /> <fld1>aaaa</fld1> <fld2>bbbb</fld2> </record> </source_file_mt>

On the receiver HTTP application, the HTTP headers are retrieved:

ALL_HTTP=HTTP_CONNECTION:close HTTP_CONTENT_LENGTH:123 HTTP_CONTENT_TYPE:text/xml HTTP_ACCEPT:*/* HTTP_ACCEPT_ENCODING:gzip HTTP_HOST:nspad391.pal.sap.corp HTTP_USER_AGENT:SAP Web Application Server (1.0;640) HTTP_DOCTYPE:SalesOrder ALL_RAW=Connection: close Content-Length: 123 Content-Type: text/xml Accept: */* Accept-Encoding: gzip Host: nspad391.pal.sap.corp User-Agent: SAP Web Application Server (1.0;640) doctype: SalesOrder

The header "DOCTYPE" is assigne the value "SalesOrder".

Troubleshooting - RFC and SOAP scenarios

RFC SENDER ADAPTER

1. The Program ID - This is Confusing !!!

Q: Where can I find the program id ?

Ans: Well, the program id can be anything, even your name. :-) But the catch here is that you should have the same in both the RFC destination and your RFC adapter.

Note: If you have read the above mentioned blog by Mike, he has used sdnweblog as the program id and the same is used in the RFC destination and also the RFC adapter

Interesting read - Question 22 of SAP note 730870^Update

An extract of the same is

"To identify a XI RfcAdapter sender channel within the SAP Gateway it is important that its Program ID is unique within this Gateway. So try to avoid using common phrases as Program ID like 'rfcadapter' or 'rfcToXmb'.

To check which Program IDs are registered at the SAP Gateway the gateway-monitor can be used via transaction SMGW. Select Goto -> Logged on Clients. Registered RFC-Servers have a System-Type of 'REGISTER_TP'. The Program ID of the registered RFC-Servrer can be found in column 'TP name'. Unfortunately the list within SMGW only shows the truncated version of the Program ID (column 'TP name'). To get the full name, the details of an entry have to be selected. As an alternative the report RSGETALL_REG_SERVERS can be executed in transaction SE38. The output of this report will show the full names of the Program ID in column 'Registered PROGID'. This functionality is also available in the function module GWY_READ_CONNECTED_SYSTEMS which can be executed in transaction SE37."

2. Application Server(Gateway) and Application Server Service(Gateway) - Where to find it ?

TCODE : SMGW -> Goto-> Parameters -> Display

You will find the required info under Attributes. Application Server(Gateway) is the Gateway hostname and Application Server Service(Gateway) is the Gateway service.
Usually the Gateway service is sapgwXX where XX is the system number.

3. The RFC destination - Trouble trouble and loads of trouble !!

a. Make sure that the RFC destination is to be created in the R3 systems and not XI.
b. If in your adapter monitoring you find a message as 'Could not start server: Connect to SAP gateway failed' then try to replace the GWHost (gateway host) with the IP of the R3 system.
c. Check out the SAP note 730870 for the FAQ on the RFC adapter.

SOAP RECEIVER ADAPTER

1. SOAP Action - Action ??????

Ref: Point 5

In case your WSDL does not have a SOAP Action defined, try with a blank SOAP Action in your Adapter. In case it doesnt succeed then try the following;

The SOAP action = SOAP operation.

You will find it under the tag . Eg. .

To find the list of Operations in your WSDL try this.
Open the WSDL in a XML Editor (eg. XML Spy). Click on the Schema/WSDL tab and you will find all the operations listed.

See the following screen shot;



2. The Target URL - Ehhh, Excuse me !!!!!

To find the Target URL search the WSDL for 'wsdlsoap:address location'. For example your search might return,



hence the Target URL is http://webservices.imacination.com/distance/Distance.jws

Also ref. point 5

3. Configure Proxy - Why should I ?

If your network involves a proxy that details have to be provided in the adapter. Also if the proxy involves an authorization, the Proxy User Authentication details need to be filled in. Else a Delivery Exception is sure to be raised.

4. SAP Note - FAQ's on the SOAP adapter

SAP Note : 856597

5. Additional Notes - XML Spy users

An Easy way of finding out your web service's right address and SOAP action using XML Spy is:

1. In the menu, Go to SOAP -> Create new SOAP request
2. Browse the WSDL file or enter the full URL of the WSDL (it should be ?wsdl)
3. Select the operation you want to access
4. After the request has been generated, go to SOAP, Change SOAP request parameters.

6. "Delivery Exception: invalid content type for SOAP:TEXT/HTML."

The reason can be the wrong address in your SOAP adapter.

7. com.sap.aii.af.ra.ms.api.DeliveryException: invalid content type for SOAP: TEXT/PLAIN

Where can I find JAR files for creating java proxies?

you can find them on your XI/PI server in folders:

aii_proxy_xirt.jar
j2ee\cluster\server0\bin\ext\com.sap.aii.proxy.xiruntime

aii_msg_runtime.jar
j2ee\cluster\server0\bin\ext\com.sap.aii.messaging.runtime

aii_utilxi_misc.jar
j2ee\cluster\server0\bin\ext\com.sap.xi.util.misc

guidgenerator.jar
j2ee\cluster\server0\bin\ext\com.sap.guid

XI: Debug your inbound ABAP Proxy implementation

Debugging of inbound proxies in WebAS 6.40 or higher

To show the debugging of inbound ABAP proxy, the implementation of the demo scenario is used. The demo scenario is available in any installation WebAS 6.40 or higher.

At first you have to set a break point in the ABAP code. Call transaction SPROXY. Expand the namespace http://sap.com/xi/XI/Demo/Airline, the node Message Interface (inbound) and the interface FlightBookingOrderRequest_In.

Double click on interface II_SXIDAL_FBO_REQUEST and get the view of the proxy object properties.

Double click on the implementing class (ABAP name) and then double click on the method name (this class has only one method).

Now you are in the inbound proxy implementation. Set the break point on the first executable line.

With help of the back button (F3) go back to the transaction SPROXY. Here you choose from menu Proxy -> Test Interface

In the next pop up check the field XML Editor to maintain the payload.

In the next screen apply suitable values or upload the XML payload of the SXMB_MONI (after mapping).

Now the inbound proxy processing should stop at the break point.

If the processing does not stop at the break point, there might be an error in the XML. Check at the result page for error messages.

Debugging of inbound proxies in WebAS 6.20

You set the break point the same way as described above.

To start the proxy test you call the report SPRX_TEST_INBOUND.

As parameters you enter the name of the ABAP interface and the method name of of the ABAP interface and check the parameter Edit Native XML

In the next screen you apply suitable values or upload the XML payload of the SXMB_MONI (after mapping).

Then you click first on save button (F11), then on back button (F3).

Now you should see your debug session. If not, check if the XML is valid.

Wanna Party ?

I might never have written this weblog but then the growing interest in the 'Party' across fellow SDNers and this particular post prompted me to formulate all that follows.

The Motivation:

The error in SXMB_MONI - Party and service not defined



The Scenario :

An IDoc to File scenario, only catch being that the Partner Type is 'KU'/'Customer'

The Development:

In IR, everything moves on as the basics for an IDoc to File scenario. I use the IDoc DESADV.DELVRY03 as the source and my intended target message is a File. Assuming that the corresponding DT, MT and an inbound MI for the file is created and the message mapping and its subsequent interface mapping is created, We move to the much awaited Configuration in ID.

Steps in ID:

1. Create a Party (File_Receiver)

While you create the party, provide the details of your R3 system with the scheme as ALE#KU and the Name your 'Partner Number'

Note: Partner Number is of length 10 so prefix '0' to adjust the same.



2. Assign the Business service (BS_SHABZ) to the party and create a receiver File adapter.



3. Assign your R3 BS under Service without Party.

4. Receiver Determination/Interface determination - The only thing new here is the entry for party in the Receiver System side.



5. Sender Agreement - No required in case of sending IDocs.

6. Receiver Agreement - Provide the Party for the receiver.



The Result:

Yes, this calls for a Party !!!!



Additional Read:

Have a look into the How to guide - Sample IDoc-XI Scenarios. The combination of that read and this weblog I guess will surely bring in a new insight to all of us.