none
Debug/LogPath for BizTalk CRM 4.0 Adapter-Has anyone got this to work? RRS feed

  • Question

  • According to the Biztalk Adapter for Microsoft Dynamics CRM 4.0 documentation it is only necessary to create a couple registry keys and then incorrect xml values will be logged.  This seems like a very useful feature to me right now.  I have added keys in the following combinations, where 'LogPath' is a string value, and 'c:\temp\logs' is the value.

    HKEY_CLASSES_ROOT\CLSID\{D38D5DCC-2B30-43b9-9C69-3BBFD0926986}\LogPath\"c:\temp\logs"

    HKEY_CLASSES_ROOT\CLSID\{D38D5DCC-2B30-43b9-9C69-3BBFD0926986}\Debug\"true"

    HKEY_CLASSES_ROOT\CLSID\{D38D5DCC-2B30-43b9-9C69-3BBFD0926986}\BizTalk\LogPath\"c:\temp\logs"

    HKEY_CLASSES_ROOT\CLSID\{D38D5DCC-2B30-43b9-9C69-3BBFD0926986}\BizTalk\Debug\"true"

    Do I need to add the keys, then reboot?  Thank you to anyone who knows the secret.

    Create a secured log path directory 

    You can use a debug feature to check whether the map used in the orchestration is generating the correct XML for Microsoft Dynamics CRM SDK.

    This feature is toggled using a registry setting. When Debug = true in the registry, the adapter checks the values in the XML (which results from a transformation/map in orchestration) against all attributes of an entity and their permissible values.

     

    Warning: Modifying the registry incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of the registry can be solved. Use the registry at your own risk.

    If there are incorrect values in the XML, an error is logged in a log file that is created in a directory specified by the registry key “LogPath” in the same registry path where “Debug” is present.

    Important: The registry path is “HKEY_CLASSES_ROOT\CLSID\{D38D5DCC-2B30-43b9-9C69-3BBFD0926986}”. This directory must be protected with the appropriate permissions and credentials so that only a user who has the appropriate credentials and permissions can create and access log files in this directory.

     

    Wednesday, August 25, 2010 8:52 PM

All replies

  • After adding the registry keys, I would try just restarting the BizTalk application and host instances and then retrying. I know the Commerce Server adapters rely on registry settings being changed and it just took a host restart for the registry settings to be picked up. You may also need to restart any running CRM services.

    If this approach does not work then I would go for the system restart.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Thursday, August 26, 2010 4:23 PM
    Moderator
  • We made changes on both the BizTalk server, and the server running CRM.  Both got rebooted; there are still no log files appearing in our designated directory after re-running the process.

    There seems to be an MS KB on the topic of setting the registry on the CRM server, titled 'How to enable tracing in Microsoft Dynamics CRM', which is very specific on the name and type of registry entries to create.  I think the same level of detail is needed for creating the registry keys for the 'Biztalk Adapter for Microsoft Dynamics CRM 4.0'.

    http://support.microsoft.com/kb/907490

     

    Friday, August 27, 2010 4:20 PM
  • Has anyone been able to produce a Debug log file using the Microsoft Documentation?

     

    Wednesday, November 10, 2010 2:44 PM
  • I would also try asking the question on a CRM-specific forum because there are not many people with Dynamics experience on these forums.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Thursday, November 11, 2010 1:41 PM
    Moderator
  • Oh man, I FINALLY have got it to work... Reflector IS your best friend...

    The Logger class looks like this:

    public static class Logger
    {
      // Fields
      private const string _adapterRegistryKey = @"CLSID\{6B8335E2-9664-4ad8-A2F6-ADBFD60FF703}\BizTalk";
      private static bool _debug = GetDebugValue();
      private const string _errorLogPathNotSet = "errorLogPathNotSet";
      private static string _logDirectoryPath = string.Empty;
    
      // Methods
      static Logger()
      {
        _logDirectoryPath = SetLogDirectoryPath();
      }
    
      public static string ConstructErrorFileName(string sendPortName)
      {
        string str = Thread.CurrentThread.ManagedThreadId.ToString(CultureInfo.InvariantCulture);
        return ("Log_" + sendPortName + "_" + str + ".log");
      }
    
      private static bool GetDebugValue()
      {
        RegistryKey classesRoot = Registry.ClassesRoot;
        bool flag = false;
        RegistryKey key2 = classesRoot.OpenSubKey(@"CLSID\{6B8335E2-9664-4ad8-A2F6-ADBFD60FF703}\BizTalk");
        if (key2 != null)
        {
          string str = (string) key2.GetValue("Debug");
          if ((str != null) && (string.Compare(str.Trim(), "true", StringComparison.OrdinalIgnoreCase) == 0))
          {
            flag = true;
          }
        }
        return flag;
      }
    
      public static void LogToFile(string fileName, string text, bool logTime)
      {
        if (_debug)
        {
          if ((_logDirectoryPath != null) && (_logDirectoryPath.Length > 0))
          {
            try
            {
              StreamWriter writer = File.AppendText(_logDirectoryPath + "//" + fileName);
              if (logTime)
              {
                writer.WriteLine(DateTime.Now.ToString(CultureInfo.CurrentCulture));
              }
              writer.WriteLine(text);
              writer.Close();
            }
            catch (Exception exception)
            {
              MSCRMAdapterUtils.WriteToEventLog(exception.Message);
            }
          }
          else
          {
            MSCRMAdapterUtils.WriteToEventLog(BTSAdapterResourceManager.GetResourcesString("errorLogPathNotSet"));
          }
        }
      }
    
      private static string SetLogDirectoryPath()
      {
        RegistryKey classesRoot = Registry.ClassesRoot;
        string str = "";
        RegistryKey key2 = classesRoot.OpenSubKey(@"CLSID\{6B8335E2-9664-4ad8-A2F6-ADBFD60FF703}\BizTalk");
        if (key2 != null)
        {
          str = (string) key2.GetValue("LogPath");
        }
        if ((str != null) && (str.Length > 0))
        {
          return str;
        }
        return string.Empty;
      }
    }
    
    
    

    As you can see, the registry key stated in the documentation is quite wrong...

    So I did what the documentation says, and insert the key in the HKEY_CLASSES_ROOT/CLSID/{}, and still nothing. I am running on a 64-bit environment, but the adapters run in 32 bit. A search through the registry helped out, and I found a fully filled registry key under HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{6B8335E2-9664-4ad8-A2F6-ADBFD60FF703}\BizTalk. Changed the Debug to true, and finally I saw the log results. Mind you: it only appears to log when you have invalid XML. If everything is OK, it doesn't log at all...

    Hope it helps someone, it's a livesaver when dealing with this blackbox...

    Erik

     

     

    Tuesday, January 4, 2011 10:51 AM
  • Hi,

    I have been using the BizTalk CRM adapter to create entities which has been going quite well until I created one which errored, my issue is that it only returns the following error

    <ErrorString>serializedForm :: Server was unable to process request.</ErrorString>

    I have also got out reflector and looked at what the adapter runtime dll does and it appears to execute the 'CreateDynamicEntity' method for the Create

    The bit I don't understand is the catch piece of code which is attached to this method, if it executed this piece in an error condition I would get the Soap Exception Detail back e.g. "A validation error occurred.  The value of 'title' on record of type 'contact' is outside the valid range." (I have validated this using pure .NET code calling the CRMService) instead all I ever get back is 'Server was unable to process request ' which is as much use as a hand brake on a horse when you are trying to bubble up meaningful error messages to the ESB exception layer

          catch (SoapException exception)
          {
            string fileName = Guid.NewGuid().ToString() + ".xml";
            string errorCode = (exception.Detail.SelectSingleNode("//code") != null) ? exception.Detail.SelectSingleNode("//code").InnerText : "";
            string str4 = (exception.Detail.SelectSingleNode("//description") != null) ? exception.Detail.SelectSingleNode("//description").InnerText : "";
            ServiceResponse response2 = new ServiceResponse("0", errorCode, str4 + " :: " + exception.Message, "0", "");
            string resourcesString = BTSAdapterResourceManager.GetResourcesString("exception");
            Logger.LogToFile(Logger.ConstructErrorFileName(this.SendPortName), resourcesString + " :: " + errorCode + " :: " + str4 + " :: " + exception.StackTrace, true);
            Logger.LogToFile(fileName, this._inputXml.OuterXml, false);
            return response2;
          }

    Any help or insight into this would be very much appreciated.

    Thanks

    AIMac

     

     

     

     

     

     

    Wednesday, January 12, 2011 12:10 PM