I recently finished a successful integration project for a customer where they were moving from FIM 2010 to MIM 2016 and from the legacy SAP Management Agent to the current SAP Web Services Management Agent – the following are observations from the journey.
The default projects published for the SAP Web Services Connector contain VB for Workflows code, rehosted so you don’t need Visual Studio to edit it but the drawback is that you’re limited to editing it inside the accompanying Web Services Configuration Tool (which is a bit….dated, frankly). Documentation for it is also very limited and hasn’t been updated since the original release of the client.
The files discovery.xml and generated.config (or cfg.config in the older version) inside the .wsconfig project can be edited using 7-Zip or similar if you need to tweak settings that currently can’t be configured inside the WSConfig tool, such as increasing the HTTP timeout value of the Web Services Connector, the default timeout being 60 seconds (standard Caveat Emptor warnings apply to modifying the content).
Note that the generated.dll file inside the .wsconfig project is re-compiled when you make changes to the Discovery settings inside the WSCONFIG tool, which in turn overwrites any manual changes made to the generated.config file so you’ll need to redo the manual changes whenever a change to the Discovery settings in the project is made.
Also, make sure you have downloaded the latest SAP Web Services Connector from Microsoft, see the Wiki on MIM Management Agents.
Be aware that since the latest versions of the Web Services connector changed build numbers from 5.3.x.x to 1.x.x.x you may need to uninstall older versions of the SAP Web Services Connector since the Windows Installer logic will reject the lower build version numbers as it (quite logically) believes it to be an older version of the connector.
For the Employee object in SAP, the following Standard SAP BAPI functions are being referenced in the pseudo-VB code and the generated.dll file that live inside the .wsconfig project that comes with the SAP Web Services Connector:
Employee:
Full Import:
BAPI_EMPLOYEE_GETDATA
BAPI_ADDRESSEMPGETDETAILEDLIST
BAPI_PERSDATA_GETDETAILEDLIST
Export/Replace
BAPI_EMPLOYEE_ENQUEUE
BAPI_PERSDATA_GETDETAIL
BAPI_PERSDATA_CHANGE
BAPI_EMPLOYEE_DEQUEUE
BAPI_TRANSACTION_COMMIT
The latest SAP Web Services Connector template (2016-03-02) expands the number of SAP object types to also include pseudo-VB code for the following object types:
_OrganizationUnit ()
Full Import:
BAPI_PDOTYPES_GETDETAILEDLIST
BAPI_ORGUNITEXT_DATA_GET
PrimaryGroup ()
Full Import:
RFC_READ_TABLE
Export Replace:
RFC_READ_TABLE
BAPI_USER_GETDETAIL
BAPI_USER_CHANGE
SecondaryGroup ()
Full Import:
RFC_READ_TABLE
Export Replace:
RFC_READ_TABLE
BAPI_USER_GETDETAIL
BAPI_USER_CHANGE
Profile ()
Full Import:
BAPI_HELPVALUES_GET
RFC_READ_TABLE
Export Replace:
RFC_READ_TABLE
BAPI_USER_GETDETAIL
BAPI_USER_PROFILES_ASSIGN
Role ()
Full Import:
BAPI_HELPVALUES_GET
RFC_READ_TABLE
Export Replace:
RFC_READ_TABLE
BAPI_USER_GETDETAIL
BAPI_USER_ACTGROUPS_ASSIGN
User ()
Full Import:
BAPI_USER_GETLIST
BAPI_USER_GETDETAIL
Export Add:
BAPI_USER_CREATE1
Export Delete:
BAPI_USER_DELETE
Export Replace:
BAPI_USER_CHANGE
Password:
BAPI_USER_UNLOCK
BAPI_USER_CHANGE
SUSR_USER_CHANGE_PASSWORD_RFC
Importing using the Standard BAPI calls from SAP and the default project from Microsoft turned out to be quite slow as we discovered after the initial deployment. The default project is using the standard BAPI calls to parse through a list of all users in the alphabet to import one entry from SAP at a time – which is probably part of the performance issue.
Fortunately, the local SAP-consultant I was working with on this project had written a custom BAPI which was collecting the users being imported into a table of rows and then sending it over the wire in one batch – we ended up dumping all the VB-code from Microsoft from the original default Web Services project and only using it for reference in a new web service project I wrote specifically to use the new custom BAPI.
In short; The performance boost from using the custom BAPI to communicate with SAP Web Services was staggering – an Import operation from SAP Web Services to the MIM Connector Space that took 6 hours with the standard BAPI calls now takes ~3 minutes using the custom BAPI. I’ll go further into this in part 2 of this series.
Further details:
BAPIs – Definition
http://help.sap.com/saphelp_46c/helpdata/en/a5/3ec8464ac011d1894e0000e829fbbd/content.htm
MIM and SAP Web Service Connector Timeouts
http://social.technet.microsoft.com/wiki/contents/articles/13675.fim-full-import-on-a-sap-web-services-management-agent-fails.aspx
Integrate SAP HR and Active Directory using Forefront Identity Manager (FIM) SAP Connector for WS
Hi Ingolfur,
Very interesting article, looking forward Part 2. Do you have a plan to publish it in the nearest future?
By the way, you mentioned 6h for standard BAPI calls and only 3 minutes for custom (really impressive results), how many employees did you extract that time (1k, 10k or 100k) and what kind of environment you had (VM, CPUs, etc.)? I just want to evaluate this approach for my scenario.
Thank you in advance.
Thanks for the response, part 2 should be out next week. The 3 minutes were for ~8000 employees, the environment was purely virtual (2 virtual CPU’s/8 Gb RAM on the MIM side) but I don’t have details from the SAP side apart from it being a physical box.
The overhead of fetching one user at a time from SAP to MIM as the standard SAP Web Services code is doing is probably between 0.3-0.9 seconds per employee – this really adds up when you’re working with thousands of entries and is probably the biggest performance bottleneck which vs. fetching all of them in one batch removes.
Hi Ingolfur
Wondering if part 2 is still on the way. I am about to commence a similar deployment shortly and any advise on MIM configuration to support this integration is greatly appreciated
Hello Ingólfur,
I am working on MIM with SAP integration, we have managed to get the web service integration working and we are able to import from SAP, but I have an issue when exporting to SAP, from MIM side the operation is successful and I can see that there are updated users with the updated values, but from SAP side there’s no update at all, also I have noticed in the event viewer that we are getting error “RABAX occurred on server side”, I’m not sure what that means.
We are using the default wsconfig file from Microsoft for the SAP employees.
Do you have any idea what is this error and how to solve it?
it’s still on the way – I’ll try to find some spare time to do a write-up on it 🙂
Pingback: MIM 2016 & SAP « Identity Cosmos
RABAX stands for “Runtime ABAp Xmessage” and indicates the SAP Web Service has sent back an error to the calling client; kernel, system level call, ABAP program errors – variable name conflict, etc.
Since you’re only getting this on an Export and succeeding on an Import I would check your variable naming – SAP is case sensitive so whatever variables you’re Exporting must match the case on the SAP side.
You need a friend on the SAP side here that can give you visibility of the error on the SAP server side, troubleshooting this only from the client end is not likely to produce good results.