Hello Biztalk friends.

I have debatable question as Title mentioned. 

We can do C# programming or call external C# assemblies using Script functoid, then when do we need really need custom functoid.

Is there any benefit of using custom functoid instead of External ass

there is no difference between the performance of the two. However, if you have a series of libraries that are used by other applications which have functions which you'd want to leverage in the BizTalk Maps also, then the way to go is External Assembly.

If however you wish to build functionality to be leveraged only through the BizTalk UI (Mapper, etc.) then use Custom Functoids.

Regards.

True!!

You basically create an external assembly when you want to use the functionality in multiple places like orchestration Expression, other applications. It is more of a common functionality that can be reused.

You can build a custom functoid and can use anywhere in the maps for transaformations.

There is harldy any difference in the performance of the two.

Rahul

Hi,

If you plan to use them is several BizTalk applications, I'd prefer to build functoids, as they can be pinned directly to the map designer and drag them to the map.

In addition you can add some useful information that will be shown in the map properties. For example, functional description or setting the mnimum and maximum number of input parameters.

But if you already have the functionality implemented in helper assemblies, it could be easier to use them directly in scripting funcoids.

Regards

Hi Umair,

Both will resolve the same problem, but I would suggest to use an external Assembly instead of custom functoid. 

They are much more approachable offer essentially identical functionality to custom functoids. 

Custom Functoids also create a Design-Time dependency that can be more problematic than simple Assemblies.

Please refer some useful article that indicates the performance of using External assembly using Scripting functoid;
http://www.bizbert.com/bizbert/2008/02/26/Understanding+The+BizTalk+Mapper+Part+12+Performance+And+Maintainability.aspx

Related thread
Custom Functoids vs Helper Class methods

This was covered in another thread recently and the prevailing opinion was helper classes over custom Functiods.

In-line C# is also perfectly fine but it's still 'better' to use helper classes.

Hi Umar,

This is my recent scenario.

Functoid:

You have a scenario where a piece of code that is required only for mapping reuse-ability across maps.

Ex: DateTime conversion some specific format (out of the box) in more than 30 fields within the same map.

      - In this case, I prefer functoid for reusability, to reduce the configuration across multiple pages.

Scripting:

      - For the same case, I give 2nd preference to use scripting, to call external to the library to achieve the same.

      - Here you need to configure the library / reference the same method around 30 times.

Depending on the scenario for your interface like the number of calls / transaction / DB calls for lookup etc...

Both are good depending on the scenario you could choose for  your interface.

Thanks, SMSVikasK

• Edited by SMSVikasK 19 hours 19 minutes ago

there is no difference between the performance of the two. However, if you have a series of libraries that are used by other applications which have functions which you'd want to leverage in the BizTalk Maps also, then the way to go is External Assembly.

If however you wish to build functionality to be leveraged only through the BizTalk UI (Mapper, etc.) then use Custom Functoids.

Regards.

• Marked as answer by Umair Ahmed 1 hour 14 minutes ago

there is no difference between the performance of the two. However, if you have a series of libraries that are used by other applications which have functions which you'd want to leverage in the BizTalk Maps also, then the way to go is External Assembly.

If however you wish to build functionality to be leveraged only through the BizTalk UI (Mapper, etc.) then use Custom Functoids.

Regards.

• Marked as answer by Umair Ahmed Sunday, September 06, 2015 5:49 AM

there is no difference between the performance of the two. However, if you have a series of libraries that are used by other applications which have functions which you'd want to leverage in the BizTalk Maps also, then the way to go is External Assembly.

If however you wish to build functionality to be leveraged only through the BizTalk UI (Mapper, etc.) then use Custom Functoids.

Regards.

• Marked as answer by Umair Ahmed Sunday, September 06, 2015 5:49 AM

there is no difference between the performance of the two. However, if you have a series of libraries that are used by other applications which have functions which you'd want to leverage in the BizTalk Maps also, then the way to go is External Assembly.

If however you wish to build functionality to be leveraged only through the BizTalk UI (Mapper, etc.) then use Custom Functoids.

Regards.

• Marked as answer by Umair Ahmed Sunday, September 06, 2015 5:49 AM

True!!

You basically create an external assembly when you want to use the functionality in multiple places like orchestration Expression, other applications. It is more of a common functionality that can be reused.

You can build a custom functoid and can use anywhere in the maps for transaformations.

There is harldy any difference in the performance of the two.

Rahul

• Marked as answer by Umair Ahmed 1 hour 14 minutes ago

True!!

You basically create an external assembly when you want to use the functionality in multiple places like orchestration Expression, other applications. It is more of a common functionality that can be reused.

You can build a custom functoid and can use anywhere in the maps for transaformations.

There is harldy any difference in the performance of the two.

Rahul

• Marked as answer by Umair Ahmed Sunday, September 06, 2015 5:49 AM

True!!

You basically create an external assembly when you want to use the functionality in multiple places like orchestration Expression, other applications. It is more of a common functionality that can be reused.

You can build a custom functoid and can use anywhere in the maps for transaformations.

There is harldy any difference in the performance of the two.

Rahul

• Marked as answer by Umair Ahmed Sunday, September 06, 2015 5:49 AM

True!!

You basically create an external assembly when you want to use the functionality in multiple places like orchestration Expression, other applications. It is more of a common functionality that can be reused.

You can build a custom functoid and can use anywhere in the maps for transaformations.

There is harldy any difference in the performance of the two.

Rahul

• Marked as answer by Umair Ahmed Sunday, September 06, 2015 5:49 AM

This was covered in another thread recently and the prevailing opinion was helper classes over custom Functiods.

In-line C# is also perfectly fine but it's still 'better' to use helper classes.

• Proposed as answer by BTSAAkhil 14 hours 3 minutes ago

This was covered in another thread recently and the prevailing opinion was helper classes over custom Functiods.

In-line C# is also perfectly fine but it's still 'better' to use helper classes.

• Proposed as answer by BTSAAkhil Friday, September 04, 2015 5:05 PM

This was covered in another thread recently and the prevailing opinion was helper classes over custom Functiods.

In-line C# is also perfectly fine but it's still 'better' to use helper classes.

• Proposed as answer by BTSAAkhil Friday, September 04, 2015 5:05 PM

This was covered in another thread recently and the prevailing opinion was helper classes over custom Functiods.

In-line C# is also perfectly fine but it's still 'better' to use helper classes.

• Proposed as answer by BTSAAkhil Friday, September 04, 2015 5:05 PM

Hi Umar,

This is my recent scenario.

Functoid:

You have a scenario where a piece of code that is required only for mapping reuse-ability across maps.

Ex: DateTime conversion some specific format (out of the box) in more than 30 fields within the same map.

      - In this case, I prefer functoid for reusability, to reduce the configuration across multiple pages.

Scripting:

      - For the same case, I give 2nd preference to use scripting, to call external to the library to achieve the same.

      - Here you need to configure the library / reference the same method around 30 times.

Depending on the scenario for your interface like the number of calls / transaction / DB calls for lookup etc...

Both are good depending on the scenario you could choose for  your interface.

Thanks, SMSVikasK

• Edited by SMSVikasK Wednesday, September 02, 2015 11:45 AM

Hi Umar,

This is my recent scenario.

Functoid:

You have a scenario where a piece of code that is required only for mapping reuse-ability across maps.

Ex: DateTime conversion some specific format (out of the box) in more than 30 fields within the same map.

      - In this case, I prefer functoid for reusability, to reduce the configuration across multiple pages.

Scripting:

      - For the same case, I give 2nd preference to use scripting, to call external to the library to achieve the same.

      - Here you need to configure the library / reference the same method around 30 times.

Depending on the scenario for your interface like the number of calls / transaction / DB calls for lookup etc...

Both are good depending on the scenario you could choose for  your interface.

Thanks, SMSVikasK

• Edited by SMSVikasK Wednesday, September 02, 2015 11:45 AM
• Proposed as answer by BTSAAkhil 14 hours 3 minutes ago

Hi Umar,

This is my recent scenario.

Functoid:

You have a scenario where a piece of code that is required only for mapping reuse-ability across maps.

Ex: DateTime conversion some specific format (out of the box) in more than 30 fields within the same map.

      - In this case, I prefer functoid for reusability, to reduce the configuration across multiple pages.

Scripting:

      - For the same case, I give 2nd preference to use scripting, to call external to the library to achieve the same.

      - Here you need to configure the library / reference the same method around 30 times.

Depending on the scenario for your interface like the number of calls / transaction / DB calls for lookup etc...

Both are good depending on the scenario you could choose for  your interface.

Thanks, SMSVikasK

• Edited by SMSVikasK Wednesday, September 02, 2015 11:45 AM
• Proposed as answer by BTSAAkhil Friday, September 04, 2015 5:04 PM
• Marked as answer by Umair Ahmed 1 hour 18 minutes ago

Hi Umar,

This is my recent scenario.

Functoid:

You have a scenario where a piece of code that is required only for mapping reuse-ability across maps.

Ex: DateTime conversion some specific format (out of the box) in more than 30 fields within the same map.

      - In this case, I prefer functoid for reusability, to reduce the configuration across multiple pages.

Scripting:

      - For the same case, I give 2nd preference to use scripting, to call external to the library to achieve the same.

      - Here you need to configure the library / reference the same method around 30 times.

Depending on the scenario for your interface like the number of calls / transaction / DB calls for lookup etc...

Both are good depending on the scenario you could choose for  your interface.

Thanks, SMSVikasK

• Edited by SMSVikasK Wednesday, September 02, 2015 11:45 AM
• Proposed as answer by BTSAAkhil Friday, September 04, 2015 5:04 PM
• Marked as answer by Umair Ahmed Sunday, September 06, 2015 5:45 AM

Hi Umar,

This is my recent scenario.

Functoid:

You have a scenario where a piece of code that is required only for mapping reuse-ability across maps.

Ex: DateTime conversion some specific format (out of the box) in more than 30 fields within the same map.

      - In this case, I prefer functoid for reusability, to reduce the configuration across multiple pages.

Scripting:

      - For the same case, I give 2nd preference to use scripting, to call external to the library to achieve the same.

      - Here you need to configure the library / reference the same method around 30 times.

Depending on the scenario for your interface like the number of calls / transaction / DB calls for lookup etc...

Both are good depending on the scenario you could choose for  your interface.

Thanks, SMSVikasK

• Edited by SMSVikasK Wednesday, September 02, 2015 11:45 AM
• Proposed as answer by BTSAAkhil Friday, September 04, 2015 5:04 PM
• Marked as answer by Umair Ahmed Sunday, September 06, 2015 5:45 AM

Hi Umar,

This is my recent scenario.

Functoid:

You have a scenario where a piece of code that is required only for mapping reuse-ability across maps.

Ex: DateTime conversion some specific format (out of the box) in more than 30 fields within the same map.

      - In this case, I prefer functoid for reusability, to reduce the configuration across multiple pages.

Scripting:

      - For the same case, I give 2nd preference to use scripting, to call external to the library to achieve the same.

      - Here you need to configure the library / reference the same method around 30 times.

Depending on the scenario for your interface like the number of calls / transaction / DB calls for lookup etc...

Both are good depending on the scenario you could choose for  your interface.

Thanks, SMSVikasK

• Edited by SMSVikasK Wednesday, September 02, 2015 11:45 AM
• Proposed as answer by BTSAAkhil Friday, September 04, 2015 5:04 PM
• Marked as answer by Umair Ahmed Sunday, September 06, 2015 5:45 AM