cancel
Showing results for 
Search instead for 
Did you mean: 

Transaction errors in "Write HCM Employee To SAP Master" via sap_importTimeValues

Former Member
0 Kudos

All, we are running 7.2 SP5 and have encountered some problems where some, but not all, terminations are not making it from HCM to IDM. The error occurs in the "Wrtie to Temp Table" pass of "Write HCM Employee To SAP Master"

The error in question that we see is typically along the lines of:

sap_importTimeValues Par:
[19000101-20150824]65412347|[19000101-99991231]99999999!!MX_FS_POSITION_ID
Attribute: MX_FS_POSITION_ID is NOT defined as Multivalue Attribute(Storage
Type) in Schema of Identity Store: 2. The values which should be imported
contain multiple values at the same point in time:
{E}{VALIDFROM=1900-01-01!!VALIDTO=2015-08-24}65412347|{VALIDFROM=1900-01-01!!VALIDTO=9999-12-31}99999999

Basically what is happening in HCM is that the user is being terminated and moved from their current job code of "65412347" to the default HR position "99999999".

I see that the script "sap_importTimeValues" has the option to:

// If the optional parameter "TRUE" is set, it means that if multiple values for a single-value attribute are passed,

// the execution doesn't stop with an error, but continues with a warning and only uses the first value!

My question is, if I enable that optional parameter for MX_FS_POSITION_ID is there any potential downside or problems that I need to be aware of?  Any insight on this would be appreciated.

Thanks,

Scott

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Scott,

You should check Jai's suggestion, as for the TRUE parameter in script "sap_importTimeValues" we have use it and it's okey.

BR,

Simona

Former Member
0 Kudos

Thanks, so here is the screen print of the job in question and it is also set to run with the audit file.  As you can see from the print, the job period is set to "Today" and not "From Today".  So the solution to the multiple MX_FS_POSITION_ID errors is to set this job to "From Today"?

What is the downside, if any, to changing the job definition to "From Today"  from "Today"?

jaisuryan
Active Contributor
0 Kudos

Hi Scott,

"Up to today" - Will bring in all past and current position

"From today" - will bring in current and future positions

"Today" - Should bring in only the current position (with split start and split end as today's date)

If you have used Today option, then you should only get "[<today's date>-<today's date>]99999999!!MX_FS_POSITION_ID "

instead of

"[19000101-20150824]65412347|[19000101-99991231]99999999!!MX_FS_POSITION_ID "


Can you try executing that report for all three options and see what data you are getting and post it here? Just put the personnel no of that user in selection criteria. Thanks.


Kind regards,

Jai

Former Member
0 Kudos

Thanks Jai, we will check it out in the development environment and see how it goes.  So with regards to the "Today" setting how would that work with future dated terminations?  If someone is set to be terminated on 10/1/2015, but the transaction is entered on 8/31/2015, when this job runs would that termination show up on 10/1 even though it was entered on 8/31?  I just want to make sure that future dated transactions don't get missed.

Thanks,

Scott

Former Member
0 Kudos

Hello Scott,

IDM will automatically create one (or mutiple) Pending Value(s) that stores these future values when user data is transmitted. So if a user is supposed to be deactivated or whatever on for example October 1st the System will automatically execute the pending value at that date and set the attribute to that value. This even works for multiple changes. So if it is clear that a user for example leaves the Company at October 1st and re-enters at November 15th and this data is sent to IDM from HR in September, IDM will create a timeline on this. On October 1st the System will deactivate the user and on November 15th reactivate the guy automatically. Changes to these timelines in HR are reflected in IDM as well. So if any future dates in HR Change and the Information is transmitted to IDM, IDM will adapt to this by altering the timeline in IDM as well.

That is the Basic way the HR extract to IDM works.

Looking at the values you receive I would assume that somebody altered the extraction query on HR side or there is just a bug? Which Version of IDM,VDS are you using and what is the Version of your ABAP System the data is fetched from? Because I can remember this Problem from a project I worked in but that was around three years ago by now.

Regards

Tobias

Former Member
0 Kudos

Thanks for the clarification Tobias.  In response to you item:

Looking at the values you receive I would assume that somebody altered the extraction query on HR side or there is just a bug? Which Version of IDM,VDS are you using and what is the Version of your ABAP System the data is fetched from? Because I can remember this Problem from a project I worked in but that was around three years ago by now.

  1. We are on IDM 7.2 SP5
  2. I will double check the ABAP version of SAP HCM
  3. The overlap problem seems to occur for some, but not all, terminations where we get the error with {E}{VALIDFROM=1900-01-01!!VALIDTO=2015-08-24}65412347|{VALIDFROM=1900-01-01!!VALIDTO=9999-12-31}99999999.
  4. Any insight around the problem you had on your project three years ago would be appreciated.

Thanks,

Scott

Former Member
0 Kudos

Hello Scott,

3 years are a long time period

We had this Problem with 7.1 at that time and I think this was due to a problem with the VDS.

What I would suggest is to test the query on HR side and see there what it delivers to rule out some scenarios. If the query produces both of these values including the dates then there is definitely a problem with the query either as a whole (if all users are affected) or on certain users (if only some are affected), but judging from your first post it only seems to affect a few. If only a few users are affected (probably all users that have a future positionID set in OM?) you should review the query and how it calculates these values. If the query however produces the correct timelines for all users but these timeline values from 1900-01-01 ... 9999-12-31 are transmitted to IDM there might be a problem on VDS side then. So if the data is computed correctly in HR but tainted in VDS you might want to to check out note 2018449 and see if that fixes the problem.

Regards

jaisuryan
Active Contributor
0 Kudos

Hi Scott,

Were you able to check the outputs by executing the query with different options?

Parameter FIXVALIDFROM was introduced around SP5 time. If you haven't set the parameter, then set it to TRUE and check. If you still face same issue, then try with FALSE as mentioned in note provided by Tobias.

I have set to TRUE and works fine till now.

Kind regards,

Jai

lambert-giese
Active Participant
0 Kudos

Hello Scott,

I had the same problem in SP7, and VDS' FIXVALIDFROM was the culprit there. Tobias and Jai have already pointed you to the relevant SAP note http://service.sap.com/sap/support/notes/2018449

Assuming your current VDS configuration has FIXVALIDFROM=TRUE (which is the default at least in SP7), then the overlap will occur whenever VDS receives a value where VALIDFROM is today or in the past. In your example, I assume that HR really sent the following data:

[19000101-20150824]65412347

[20150825-99991231]99999999

However, that data was received by VDS only on 20150825 or later. This could occur if your HR export is scheduled in the early morning hours, or if it is scheduled in the evening, but running so long that it will finish (and send data via LDAP to VDS) only after midnight.

What happens now in VDS with FIXVALIDFROM=TRUE is that the second line will implicity be changed:

[19000101-20150824]65412347

[19000101-99991231]99999999

Now you have an overlap in the HCM staging area, which is - at least from an HR business perspective - wrong.

In SP7, I could fix this problem by changing FIXVALIDFROM parameter of the VDS config to FALSE. After this change, VDS will leave the VALIDFROM dates alone, which is what I want.

Importing these "non-fixed" values from the HCM staging area into SAP Master IDs works for me without any tweaks to sap_importTimeValues. I didn't need to set the TRUE parameter to accept multi-value for attributes that are actually single-value, becaue that situation no longer occurs.

A word of caution here: I guess FIXVALIDFROM has originally been introduced for a reason. I guess at some point in time, IdM may have had problems with importing HCM staging area values with a past validfrom into SAP Master IDS. However, I cannot reproduce such problems in SP7.

So while not sure whether my approach is applicable to your situation on SP5, it might still help understand the problem.

Best regards,

Lambert

Former Member
0 Kudos

Thanks Jai, we have been trying out the HCM extract settings before doing this in prod.  So far everything works as expected in dev with the "From Today" setting and w are creating a number of test accounts to create a production load.  In prod, this all works fine for a single account so it is a bit frustrating trying to recreate the error in any environment on a consistent basis.

I did check the VDS settings and FIXVALIDFROM is set to true.  We will experiment with the false setting as well.

Thanks for all the hlep,

Scott

Former Member
0 Kudos

Thanks Lambert, this description is very help and really shines a light on what is going on.  Your problem seems to mirror our current errors.  Does anyone else have an opinion on setting FIXVALIDFROM to false in SP5?

Thanks,

Scott

Former Member
0 Kudos

Just to finish this one off, our HCM version is:

SAP HR : Release 604, SP level
0066, Support Pack SAPKE60466   Human Resources

EA-HR: Release 607, SP Level
0017, support Pack SAPK-60717INEAHR      SAP
Enterprise Extension HR

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi just to time this off the suggestions on this thread worked.  We set FIXVALIDFROM=False and updated the HCM extract job to send items "From Today".  The fix has been running without problems for the last 10 days.  I really appreciate everyone's assistance on this.

Thanks,

Scott

jaisuryan
Active Contributor
0 Kudos

Hi Scott,

How is your HCM-IDM report setup in HCM system?

Check if it is set to run with option "From Today" as shown below? If so, then you should get only one (current) position id for the user.

Kind regards,

Jai

Former Member
0 Kudos

Thanks for the suggestions Dominik and Jai.

  1. Dominik, to your first point yes that is the raw data that we are getting out of HCM through VDS.
  2. Jai, thanks for the suggestion we will take a look at the HR-LDAP extractions and check the settings.

Scott

former_member201064
Active Participant
0 Kudos

Hello Scott,

so you really get these two lines from HR without manipulating them / adding the second row before?

[19000101-20150824]65412347

[19000101-99991231]99999999


The problem is that both values would be valid from low date (the year 1900) until 24th of August. The IdM cannot handle this.

At first I would check whether the extract is set up correctly in the HR system; if there are same mismatchings or whether the two attributes for split begin and split end are missing.


If anything does not help, I would write an own javascript. Something like z_reformatTimeValues. The valid from of the time slices have to be rewritten accordingly. If there are more then two time slices they have to be all rewritten:

[19000101-20150924]87654321

[19000101-20160824]12345678

[19000101-99991231]99999999

to

[19000101-20150924]87654321

[20150925-20160824]12345678

[20160825-99991231]99999999

After that the sap_importTimeValues script can be used.


If you only want one value, you can use sap_cutDate. Or at least something like that. I would use an own script which selects the time slice with 99991231 and then return the value of that one, without the {validfrom...}


You could use that parameter, yes. But I wouldn't rely on that script because you could receive the "wrong/old" value.


Best regards


Dominik