Scripting functoids
Ever wondered how the scripting functoid generates the code to perform what you have put into the buffer, how the checking for validity is done and the methods you define are published?
In reality, Microsoft.BizTalk.BaseFunctoids.InlineScriptCompiler compiles all scripting functoids to the target language. It generates an assembly by using CodeDOM and ICodeCompiler services, in about the same way as outlined in e.g. KB Q304655.
Let's say we have implemented an inline script functoid which defines a C# method like this one:
Just my 2 cents...
In reality, Microsoft.BizTalk.BaseFunctoids.InlineScriptCompiler compiles all scripting functoids to the target language. It generates an assembly by using CodeDOM and ICodeCompiler services, in about the same way as outlined in e.g. KB Q304655.
Let's say we have implemented an inline script functoid which defines a C# method like this one:
public string MyConcat(string param1, string param2)The InlineScriptCompiler would generate an assembly like this:
{
return param1 + param2;
}
using System;Considering the above, I would argue that combining your logic into one external assembly would be better for a lot of reasons, including code re-use, documentation purposes (try using NDoc on inline script functoids :-p), functional grouping, the ability to use resources, external assemblies, etc.
namespace BizTalkMapper
{
public class FunctoidInlineScripts {
public string MyConcat(string param1, string param2)
{
return param1 + param2;
}
}
Just my 2 cents...
0 Comments:
Post a Comment
<< Home