External Data Loads for CRM 4.0 using XIF adapter
What is the XIF adapter?
In release CRM 3.X SAP introduced a new adapter for the CRM middleware as a mechanism to load and retrieve data from a CRM system. This adapter was called the eXternal InterFace Adapter or XIF for short. The adapter is series of APIs that provide external access to the CRM middleware.
Traditionally in the R/3 development we used BAPIs to change data externally. The XIF concept is similar to BAPIs with the exception that it was designed for multiple layers of access. The three primary access methods are RFC, IDOC and SOAP. These access methods provide the necessary means to use the XIF adapter.
Getting Started with XIF the easy way:
First off, using the XIF IDOCs or RFCs is merely a mapping exercise. I have seen many questions on how to map the function module parameters. There is an easy way to do this regardless of how you are using XIF.
I recommend using LSMW to determine your mapping. The benefits of this tool, is you can build a mapping to the XIF adapter without writing any code. This allows for rapid tweaking of the mapping to see how things will work.
Now unlike many other things delivered by SAP, the documentation for the XIF contains 90% of what you need in order to use it, for either RFC or IDOC. The key part is how SAP names the XIF function modules and some of your most common business objects:
SAP follows the convention for the inbound XIF function modules:
Where * = Business Object
The most common and useful objects are:
- ORDER Business Transactions
- PARTNER Business Partner
- PRODUCT_MATERIAL please note that in CRM terminology that the PRODUCT object is actually a CRM product catalog. PRODUCT_MATERIAL is what we would consider equivalent to an R/3 material master.
If you look at the code for each function module the general outline looks quite similar:
- Determine where the message is being imported
- Build a BDOC header for the corresponding BDOC object
- Map the XIF structure to a corresponding BDOC structure
- Start the middleware flow passing in our newly generated BDOC
- Determine errors and call commit work or rollback depending on success or error.
Now this requires middleware on the CRM system to be configured. We do not need to point CRM to an R/3 backend, but we do need to define a site type defined for the XIF adapter.
After keeping this all in mind here is the recipe for building the LSMW project:
- Create a new project
- Setup IDOC inbound processing for the project
- In LSMW define the business transfer as IDOC processing
- Create a test data structure
- Map the values to the test structure
- Convert in the test file and determine if successfully
- Adjust the mapping and re-run until successful
Now the details for each step
I am not going to cover in detail the exact steps for each part of the process. I am going to cover the pain points which are not obvious, during the setup in LSMW. For now a good working knowledge of LSMW along with the notes below will lead you to success.
You will require a new LSMW project to be setup. The most difficult parts of the initial configuration will be the IDOC Inbound Processing Setup and a few issues with mapping.
IDOC Inbound Processing
This is the key to make this work. From the main screen of LSMW choose the menu option:
Settings->IDOC Inbound processing
We need to make sure we have two things setup on this screen: a file port and a partner number. The file port should follow the standard setup for LSMW usage. For the partner number a partner needs to be maintained that has the XIF message type on the Outbound and Inbound Parameters. For Products use message type: CRMXIF_PRODUCT_MATERIAL_SAVE. The Basic type on the IDOC type will be CRMXIF_PRODUCT_MATERIAL_SAVE01.
LSMW Data Object Definition
The object data definition should be of message type CRMXIF_PRODUCT_MATERIAL_SAVE, and basic type CRMXIF_PRODUCT_MATERIAL_SAVE01.
Test data structure
The minimum data to load a product master in CRM is typically a product id code, description, and base unit of measure. Your file will need to contain this data at a minimum.
Mapping files to test structure
Products in CRM are different from your typical R/3 material. A product in CRM does not have any attributes until assigned to a category. Therefore we will need to assign our product to a category in order for it to load. The hierarchy will will commonly use is ‘R3PRODSTYP’ and category id of ‘MAT_FERT’. This corresponds to finished goods type of R/3. If you are not connected to an R/3 system you will need to setup a product hierarchy and assign the basic product views to that category.
Another point to make is that all segments you map will require at least a logical system identifier. The easiest way to handle this is to retrieve the current logical system from T000 with a small mapping routine in LSMW. The logical system indicates where the data originated from, and in this case we want the logical system to show that CRM is the origin of this data.
A project that I built to load a product with an ID, description and UOM mapped the following segments
CRM Middleware Setup
In transaction SMOEAC you will need to define a new site for the XIF. Create a new site of type External Interface for IDOC’s. You will then need to maintain under the site attributes the EDI partner setup for your LSMW project.
The final issue is the mapping and trying to decipher the XIF data structures. In general this again is relatively straight forward. If you understand CRM data structures and underlying tables then you will have no problem. If you dont understand the CRM data structures then mapping will be difficult at the least. We may cover CRM data structures in a future blog.