Identity Manager SAP driver & Position Removal

  • 3449102
  • 17-May-2007
  • 30-Apr-2013


Novell Identity Manager Driver- SAP HR


We are looking the function in SAP-HR driver, how to implement the removement of infotypes in object type S and how to manage the following functions, like login diasable, because the jobfunction do not need a PC in the future. Example: A Jobfunction (Objecttype S) has PC-Workstation assigned in infotype 1010, so the assigned User (Objecttype P) must be able to login -> Login enable, that functions because we get a dataset P1010. if you remove this assignment you get only headerinfo for this infotype without data, which means, that assignment is deleted. Now we have no data to compare this event, so that we can disable login for that user.

What information can we ask for or compare with?"

Problem is to do some task, if special infotypes in SAP are deleted. We have no datafield we can use o match or transform, only header information. It is based on the idoc-structur of SAP and ALE. One example: We have an Position (Organizational Rule) with an infotype "Hilfsmittel" P1010 and a value of 002 for the SAP attribute P1010:HILFM:none:86:3. This means, that the position has a PC ans so the login for the associated Person (User) must be enabled. If the PC is removed of that position, we delete that infotype. Than we gat an idoc with only the header info, that we have a change for position xyz and infotype 1010, but without any value (this means " no Hilfsmittel/Utilities"). The result is, that the login of the associated user must be disabled!"


Deletes of an infotype field or an entire infotype record do not appear in an Idoc i.e. the removed values are not present in the Idoc. Removing a field or deleting an entire infotype record generates an Idoc because something has changed on the object in SAP.

If a value is removed from an infotype, the the driver will generate a remove-all-values in the XDS document for the infotype field as the field is blank i.e. the Idoc will contain a segment for the infotype but the actual field will be blank. (if the field value changes to a new value the driver generates a remove-all-values followed by an add-value with the new value - this means that the driver cannot handle multi-valued infotype fields!)

In this case they are actually deleting the entire Infotype record from the Position rather than just the field value. Hence the Idoc only contains a header i.e. it will not contain a segment record for infotype 1010. Consequently there will won't be a remove-all-values in the XDS document for the infotype field.

Idocs only contain infotype segments for the infotypes that have changed since the last time an Idoc was generated i.e infotypes that have had a field value added or removed.

So we cannot assume that "if an infotype segment is not present in an Idoc that the inoftype record has been deleted", as the segment may also not be present in the Idoc as the infotype may not have changed.

Now comes the big question of how to get around this lovely SAP feature.

One workaround would be for them to change the process in SAP so that instead of deleting the entire infotype record they change the value in field P1010:HILFM:none:86:3 to a value that indicates that no resource has been assigned e.g. 000 or blank. Then they would see either 000 being added to the field in the XDS document or if they set the value to blank just a remove-all-values.

There are two other solutions as well.

1. The customer might write an UserExit, which fills the 'emptied' value with a 'dummy' value, so a driver policy can identify this situation. The advantage is, that the look and feel of the SAP GUI does not have to change.

2. The iDoc provided by SAP HR, does have a header, which shows, that something has been changed in the SAP infotype. But because there is no value, the current driver AppShim filters this event out.

The current AppShim does have some limitations what infotypes can be queried. This limitation belongs to these infotypes:

- Personal Data (Infotype 0002)

- Private Address (Infotype 0006)

- Communication (Infotype 0105)

- Internal Data (Infotype 0032)

So even if the publisher is capable to consume infotype 1010, it's not possible to query for the current value of this infotype.