Error encountered while executing the Map transformation


  • Hi,

    Its regarding failure in map transformation.

    I have deployed one BizTalk 2006 project in production. I haven't encountered the map failure in my testing environments but strangely i am facing failure in map in production.

    Note: I am not getting this for all messages. If i resubmit the failed message its getting processed with no error. And its happening one message for every 200 to 500 messages.

    Following is the error message i am getting-

    Error encountered while executing the transform
    <ProjectName>.<MapName>. Error:Transformation failed..  
    at Microsoft.XLANGs.Core.Service.ApplyInMemoryTransform(Type mapRef, TransformMetaData trfMetaData, Object[] outParams, Object[] inParams)    
    at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, Object[] outParams, Object[] inParams)    
    at <Proj Name>.<File name>.segment3(StopConditions stopOn)    
    at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)

    Please help me in solving the production issue.

    Thanks and Regards

    Monday, December 22, 2008 3:59 AM

All replies

  • Hi

    Can you elaborate a little on the problem?

    Are there any other warnings or error (in the application event log) that appear at the same time as the failure ?
    How big are those messages ?
    Any special things in the maps (databes functoid, own scripts ...) ?
    Are you receiving  those 200 to 500 messages at one time ?

    Monday, December 22, 2008 2:58 PM
  • Did you get OUtOfMemoryException?
    MSMVP VC++
    Monday, December 22, 2008 4:22 PM
  • Hi,

    Thanks for the reply:)

    1.No errors and warnings.
    2.Max 3KB size messages.
    3.I am using my own script functoids and which intern hits the DB.But i have logs for this and its executing perfectly.
    4.In a span of 1 day i used to get 200 to 500 Msg's.
    5. No, i didn't get OUtOfMemoryException.

    Thanks in advance
    Tuesday, December 23, 2008 3:55 AM
  • Hi,

    does the database values change regularly?
    there might be possibility that many instances of map trying to access the database and there could be some deadlock or delay in response from db this might cause the map to fail.
    Tuesday, December 23, 2008 3:36 PM
  • Hi again,

    As previously said, try to double check the code doing the database access, this seems the most likely place where something could go wrong.

    You can't reproduce this in your development or test environment ?
    Wednesday, December 24, 2008 2:58 PM
  • I suspect there may be a concurrency issue in your functoid script.  Do you test with message volumes that are reflective of your production environment?  If you could show us some of the code and the way you are implementing it in your functoid - this would help alot.  Are you using static methods?
    Friday, January 2, 2009 4:13 AM
  • First, I'd want to reproduce this in dev.  Since it is a map problem and probably some kind of conflict, set up in dev a file drop, have it pick up your files and run them through whatever transform you normally do, and out another file drop. Then drop 10,000 files on it at once and see it reproduce the problem. 

    Then start eliminating one thing at a time.  If the map is in an orchestration, take out the orchestration and bind the map to a port and see if that solves it.  If there are database lookups, substitute one at a time with a hard coded value and see if it is a particular one that causes it.  

    If these don't narrow it down to a specific issue, then I would start thinking the system runs out of something under load, perhaps threads.  There are registry settings for tuning thread availability, you might find your failure threshold and then play with these settings until the failure threshold changes. 

    Finally, think about balancing out your production load better.  One host instance to publish to the message box, one to take finished messages out when done, and one for just map transformations.  By throttling adapters and allocating priorities between host instances you can probably keep your map instance below the failure threshold.   This is the least attractive solution because it doesn't show you the cause and give you the path for the optimal solution, you're just sort of fumbling around until you get a balance that works - probably a sub-optimal one.  But it can get the job done. 

    Let us know how it turns out, these kinds of scaling problems are always interesting to me. 

    The Dude Abides
    Monday, January 5, 2009 12:46 AM