none
FIM MA Export - Attribute Representation Failure and Odd Export Behavior

    Question

  • I've been noticing some bizarre FIM MA export behavior which started with the FIM Service throwing the failed-creation-via-web-services with the stack trace of:

    Fault Reason: The request message contains errors that prevent processing the request.\r\n\r\nFault Details: &lt;RepresentationFailures xmlns="http://schemas.microsoft.com/2006/11/ResourceManagement" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"&gt;&lt;AttributeRepresentationFailure&gt;&lt;AttributeType&gt;EmployeeType&lt;/AttributeType&gt;&lt;AttributeValue&gt;Employee&lt;/AttributeValue&gt;&lt;FailureMessage&gt;Exception: ValueViolatesRegularExpression Target(s): <Removed Account Name>
    Stack Trace: Microsoft.ResourceManagement.WebServices.Exceptions.InvalidRepresentationException: ValueViolatesRegularExpression
       at Microsoft.ResourceManagement.ActionProcessor.ActionDispatcher.ValidateObjectAttributes[T](RequestType request, Guid objectIdentifier, String objectTypeName, IEnumerable`1 parameters, OperationType operationType)
       at Microsoft.ResourceManagement.ActionProcessor.ActionDispatcher.ValidateInputRequestCreate(RequestType request)
       at Microsoft.ResourceManagement.ActionProcessor.ActionDispatcher.ProcessInputRequest(RequestType request)
       at Microsoft.ResourceManagement.WebServices.RequestDispatcher.ExecuteAction(RequestType request)
       at Microsoft.ResourceManagement.WebServices.RequestDispatcher.ExecuteAction[ResponseBodyType](RequestType request)
       at Microsoft.ResourceManagement.WebServices.RequestDispatcher.DispatchRequest[ResponseBodyType](RequestType request, Guid requestIdentifier, Object redispatchSingleInstanceKey, Boolean isRedispatch)
       at Microsoft.ResourceManagement.WebServices.RequestDispatcher.DispatchRequest[ResponseBodyType](RequestType request)
       at Microsoft.ResourceManagement.WebServices.ResourceManagementService.Create(Message request)&lt;/FailureMessage&gt;&lt;AttributeFailureCode&gt;ValueViolatesRegularExpression&lt;/AttributeFailureCode&gt;&lt;AdditionalTextDetails&gt;The specified attribute value does not satisfy the regular expression.&lt;/AdditionalTextDetails&gt;&lt;/AttributeRepresentationFailure&gt;&lt;CorrelationId&gt;b48b0fb1-a569-461b-ac41-a17e8bd8d3bd&lt;/CorrelationId&gt;&lt;/RepresentationFailures&gt;


    Troubleshooting steps:

    1.) I've checked the validation string, which is ^(Contractor|Employee)?$, on both the EmployeeType binding and the attribute, both of which match, and I still receive the above error message.

    The source of the value is an HR MA constant attribute flow of "Employee" so it can't be any case or leading\trailing white space issue.

    2.) Restarted the FIM Service and IIS Admin service on all FIM Service servers

    3.) Cleared the FIM MA Connector Space

    4.) Cleared the HR MA Connector Space

    5.) Ran a Full Import and Full Sync on both the FIM MA and HR MA

    Now here's where it gets weird.......some of the accounts get created and some fail. Also, if I rerun the export the failed accounts are created. In addition during the confirming import instead of seeing the newly exported person object count of say 5 updates, or whatever is the exported person count, I see 5 Adds and 50 updates. The additional updates seem to be caused by the workflows updating person object data on the FIM Service side but I've never seen that kind of behavior before.

    With that said has anyone seen that kind of behavior and if so how did you resolve the problem?

    Any help would be greatly appreciated!

    Thanks,

    Austin

    jeudi 1 août 2013 14:25

Toutes les réponses

  • Update:

    My assumption was that the FIM Service wasn't processing requests as quickly as the FIM Sync Service was trying to run the confirming import. That appears to be the case since I am running the Export then running the Import and not combining the Export and Import run profiles.

    Still would like to know if this is expected behavior or there is a configuration change that I could make to limit the processing?

    jeudi 1 août 2013 15:07