Tuesday, December 4, 2007

ILM (MIIS) and the Microsoft ERP Management Agent - Part 2

In part of my last post, here we should do an overview of the SAP .NET Connector. Essentially, it is a programming environment inside of Visual Studio that enables us to communicate between the .NET platform and SAP Systems. Communication is facilitated through proxy classes which call and/or invoke BAPI functions in SAP. The connector support both SAP RFCs and Web Services which allow you to write various applications using any .NET language. Pretty straight forward, huh?

Anyhow, the connector is made up of several parts. As I mentioned, first it’s pretty tightly integrated with Visual Studio for generating SAP proxies. The proxies are used to call BAPI functions through either the SAP RFC protocol (librfc32.dll) or via SOAP. Do note, per the documentation...Release 4.6D does not have SOAP support while systems starting from 6.20 can use either. At the moment, the most current version of the connector is built for .NET 2.0 (SAP Connector for Microsoft .NET 2.0). Additional dlls that are part of the assembly is the SAP.Connector.Rfc.dll and LibRfc.dll. (LIBRFC32.dll, is in Release 6.20 and higher). The diagram below, details the runtime architecture and how communication is facilitated using the .NET Connector.




ILM (MIIS) and the Microsoft ERP Management Agent - Part 1

In my current project, I’ve had the opportunity to work with the Microsoft ERP Management Agent for SAP. As many already know, SAP is a huge applications and a common connected data source which in most (or some) cases acts as the authoritative source for HR related data. MIIS can be used to facilitate or broker identity data and identity management related tasks to and from this connected data source and to many others. In my opinion, MIIS and SAP integrate very well which I thought I’d write about how MIIS connects to SAP to synchronize identity data to and from the connector space. From here, I hope you can get a better understanding on how to integrate SAP into your existing MIIS environment.

Prior to the release of the ERP MA by Microsoft, MIIS developers connected to SAP systems by custom XMAs using the SAP .NET Connector. For example, Oxford Computer Group had developed a management agent for SAP which has been proven successfully in many environments way before the Microsoft ERP MA was even released. Regardless, here is how connectivity is accomplished using the ERP MA from Microsoft.

Before I start, the Microsoft ERP Management Agent can be downloaded from the following link or obtained within the ILM 2007 FR1 installation media.

Microsoft Enterprise Resource Planning Management Agent for SAP

The base requirements for this management agent are:

  • Microsoft Identity Integration Server 2003 SP2 or ILM 2007
  • The SAP .NET Connector 2.0
  • Microsoft .NET Framework, version 1.1 or higher

In order to connect to SAP, you should first understand some concepts of SAP.

  • BAPI (Business Application Programming Interface) – a function that performs a specific operation inside the SAP environment
  • InfoTypes – structures used as parameters to BAPIs
  • RFC (Remote Function Calls) – a method for accessing a BAPI from another computer via the network
  • SAP Connector for Microsoft .NET 2.0 – a managed component from SAP that enables RFC to BAPIs in a SAP application server

It’s pretty late now, so in my next part I will write more details on how the SAP .NET Connector works and how it relates to MIIS and the ERP MA.

Tuesday, November 27, 2007

ERP MA bug in ILM 2007 FP1

Apparently there is a known bug in the ERP MA for SAP that comes with ILM 2007 FP1. This bug prevents you from configuring the outbound flow of an anchor attribute. When mapping an attribute to csobject.anchor, this prevents you from setting the flag which defines this attribute as an identity for the object and prevents you from exporting when invoking a BAPI that needs the reference.

Microsoft is aware of the bug which might be fixed next week; however the expectation should be assumed for mid-January.

So far, I’ve still using the version of the MA downloadable from the following link which is working fine.

Thursday, September 13, 2007

Setting Terminal Service Properties in .NET

I recently had the requirement of managing Terminal Service properties in AD by means of MIIS. If you've ever been tasked with this, you may have noticed there are many VBScript and C++ snippets online with very few .NET examples. Therefore, I've decided to post how to accomplish this in .NET for those interested.


Initially, you'd think this is pretty easy...why couldn't I just flow any value through to AD using an advanced attribute flow within an MA rule extension? Well, not in this case. If you look into a user objectClass in AD through ADSIEdit, you'll notice these attributes are not directly exposed. Although I was able to populate some of the values through System.DirectoryServices, not all were accessible. Further research uncovered you can manage Terminal Service properties using the ADSI Extension for Terminal Services User Configuration. This extension is an assembly that allows you to manage Terminal Server user properties though the IADsTSUserEx Property Method. Below is sample code I used to test the functionality.


using TSUSEREXLib;
using System.DirectoryServices;
using System;
using System.Collections.Generic;
using System.Text;

namespace Set_Terminal_Service_Properties
{
class Program
{
static void Main(string[] args)
{
string acctName = "chrisca";
string tsHomeDrive = "H:";
string tsHomeDirectory = "\\\\servername\\tshomedirectory\\";
string tsProfilePath = "\\\\servername\\tsprofilepath\\";
int enableLogon = 1; // enable terminal service logins

DirectoryEntry entry = new DirectoryEntry
("LDAP://CN=Chris Calderon,CN=Users,DC=corp,DC=contoso,DC=com");
ADsTSUserEx oUser = (ADsTSUserEx)entry.NativeObject;
oUser.AllowLogon = enableLogon;
oUser.TerminalServicesHomeDirectory = tsHomeDirectory + acctName;
oUser.TerminalServicesHomeDrive = tsHomeDrive;
oUser.TerminalServicesProfilePath = tsProfilePath + acctName;
entry.CommitChanges();
entry.Close();
}
}
}

As you can see, you use the extension in the same manner as you would any ADSI statements. A key item to consider is, the properties that the Terminal Service User component exposes is not directly mapping individual AD attributes. Common with ADSI, when calling these methods to load the property values of the ADSI object, it stores this information into the property cache of the directory store. Only until the IADs::SetInfo method is called (or something equivalent), the property value changes are saved.


This component consists of one DLL (TSUSEREX.DLL), located within the %SystemRoot%\System32 directory. In order to use the IADsTSUserEx interface, you must reference this assembly within your project. The link below provides a table that lists the property methods of the IADsTSUserEx interface.


IADsTSUserEx Property Methods Details


My original goal is to eventually build an XMA for auxiliary attributes; however the core requirement to do that is to identify a method to access (read/write) these attributes.