wiki

Codit Wiki

Loading information... Please wait.

Codit Blog

Posted on Friday, August 6, 2010 8:09 AM

Korneel Vanhie by Korneel Vanhie

Translating in pipeline using the Bing API

The Bing API allows you to get results from multiple sourcetypes, one of them being the Translation SourceType.

More Info on the API can be found here.

The SDK comes with some nice samples and can be found here.

As a practise we are going to do a query from a BizTalk Pipeline component  to translate a field configured by an XPath.

In design we need to define a source language, destination language and the XPath to the field we will translate.

TranslationLanguage is just an enum to facilitate configuration in pipeline design time.

private Helper.TranslationLanguage _SourceLang;
private Helper.TranslationLanguage _DestLang;
private string _XPath; 

public Helper.TranslationLanguage SourceLanguage
{ get; set; } 

public Helper.TranslationLanguage DestinationLanguage
{ get; set; } 

public string XPath
{ get; set; }

Next we modify the Execute function of the component to call the Tranlate method we will define further on, to modify the message.

A good way to do this is by using the XPathMutatorStream. More info on XPathMutatorStream can be found here.

IBaseMessage Microsoft.BizTalk.Component.Interop.IComponent
Execute(IPipelineContext pContext, IBaseMessage pInMsg)
{
          IBaseMessage biztalkMessage = pInMsg;
          XmlReader reader = XmlReader.Create(pInMsg.BodyPart.Data);
          XPathCollection xpaths = new XPathCollection();
          xpaths.Add(this._XPath);
          ValueMutator mutator = new ValueMutator(handleXpathFound);
          pInMsg.BodyPart.Data = new XPathMutatorStream(reader, xpaths, mutator);
          return pInMsg;
} 

private void handleXpathFound(int matchIdx, Microsoft.BizTalk.XPath.XPathExpression matchExpr, string origVal, refstring finalVal)
{
          finalVal = Helper.Translate(SourceLanguage, DestinationLanguage, origVal);
}

Finally we’ll send a request to the Bing API using the XML protocols ( we are BizTalk Developpers after all … ).

We build the query using the arguments provided and return the translation:

public static string Translate(TranslationLanguage SourceLang,  TranslationLanguage DestLang, string text)
{
          LoadLanguages();
          HttpWebRequest request = BuildRequest(_Languages[SourceLang], _Languages[DestLang], text);
          try
          {
                    HttpWebResponse response = (HttpWebResponse)request.GetResponse();
                    XmlDocument document = new XmlDocument();
                    document.Load(response.GetResponseStream());

                    XmlNamespaceManager nsmgr = new XmlNamespaceManager(document.NameTable);
                    nsmgr.AddNamespace("tra", "http://schemas.microsoft.com/LiveSearch/2008/04/XML/translation");

                    return document.DocumentElement.SelectSingleNode("./tra:Translation/tra:Results/tra:TranslationResult", nsmgr).InnerText;
          }
          catch (WebException ex)
          {
                    throw new ApplicationException("Web Error while translating",ex);
          }
}

static HttpWebRequest BuildRequest(string SourceLang, string DestLang, string text)
{
          string requestString = "http://api.bing.net/xml.aspx?"
          + "AppId=" + AppId
          + "&Query=" + text
          + "&Sources=Translation"
          + "&Version=2.2"
          + "&Translation.SourceLanguage=" + SourceLang
          + "&Translation.TargetLanguage=" + DestLang;

          HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(        requestString);

          return request;
}

 

Time to test: Create a BizTalk project with

A schema for testing:

 

A pipeline with our new component. We define the xpath to the Value Record, the source and destinationlanguage. I created pipelines to translate to Dutch and French from English:

 

Deploy in BiZtalk, create Receiveport with Receivelocation, 2 Sendports with a filter on the Receiveportname and our pipeline to translate to French and Dutch.

 

Drop a test message:

 

<ns0:TestTranslatorSchema 

xmlns:ns0="http://TestTranslator.TestTranslatorSchema">

  <Value>What language is this written in?</Value>

</ns0:TestTranslatorSchema>

 

And observe the results:

<ns0:TestTranslatorSchema 

xmlns:ns0="http://TestTranslator.TestTranslatorSchema">

  <Value>Quelle langue c'est écrit ?</Value>

</ns0:TestTranslatorSchema>

 

<ns0:TestTranslatorSchema 

xmlns:ns0="http://TestTranslator.TestTranslatorSchema">

  <Value>In welke taal is dit geschreven?</Value>

</ns0:TestTranslatorSchema>

Korneel Vanhie, CODit

 

Categories: BizTalk
written by: Korneel Vanhie

Posted on Thursday, October 3, 2013 4:58 PM

Sam Vanhoutte by Sam Vanhoutte

This blog post gives a feature comparison between Windows Azure BizTalk Services and BizTalk Server.

I have given quite some sessions and presentations recently on Windows Azure BizTalk Services.  We had the opportunity to work together with the product team on WABS as a strategic Launch Partner.  I had a lot of discussions and questions on the technology and a lot of these questions were focused on a comparison with BizTalk Server…

Therefore, I decided to create this blog post, I created a comparison table, much like the comparison tables you can see on consumer web sites (for mobile phones, computers, etc…)

If you need more information or have some feedback, don’t hesitate to contact me.

In the mean time, I also came across the following wiki on msdn, that does a good overview too: click to open

Connectivity & adapters

Some adapters are not applicable in cloud services (File, for example), where others are.  BizTalk Services has a lot of adapters not available.  Custom adapters can only be written through the outbound WCF bindings.

  BizTalk Server BizTalk Services
File Yes No (cloud only)
FTP Yes Yes
SFTP Yes Yes
SOAP Web services Yes Yes
RESTful services Yes, no JSON Yes, no JSON
HTTP Yes HTTP
Email Yes Through custom WCF binding
Outbound only
SQL Yes Through adapter service
SAP Yes Through adapter service
Siebel Yes Through adapter service
Oracle DB Yes Through adapter service
Oracle Apps Yes Through adapter service
SharePoint Yes Through custom WCF binding
Outbound only
MQSeries Yes No
Service Bus Yes Outbound only (Relay + Messaging)
Azure Blob storage Through custom adapter Yes

Core messaging capabilities

The biggest difference here is the routing pattern that is totally different between both products.  More can be read in an earlier post: Windows Azure Bridges & Message Itineraries: an architectural insight.  If you want durable messaging, Service Bus queues/topics are the answer, but the biggest problem is that WABS cannot have subscriptions or queues as sources for bridges.

 

BizTalk Server

BizTalk Services

Durable messaging

Yes, MessageBox

Only through service bus and custom polling

Volatile messaging

No, always persistence

Yes

One-to-many routing

Yes

No, first match routing. Only through service bus topics

Property promotion

Yes

Yes

Retry mechanism

Yes

No

Alternative routing

Yes

No

Failed Message Routing

Yes

No

 

Message processing

We have good feature parity here on these items.  The main thing missing would be JSON support.  For that, we have written a custom component already that supports JSON.

 

BizTalk Server

BizTalk Services

Transformation

Yes

Yes

Schema Validation

Yes

Yes

Property promotion

Yes

Yes

Flat file processing

Yes

Yes

XML processing

Yes

Yes

JSON processing

No

No

Binary processing / routing

Yes

No, maybe in passthrough (to be checked)

EDIFACT processing

Yes

Coming soon

X12 processing

Yes

Yes

Management & deployment experience

In my opinion, this is where the biggest challenge lies for WABS.  Administration and management is really not what we are used with BizTalk Server.  Configuration is very difficult (no binding file concept) and endpoint management is also not that easy to do.

 

BizTalk Server

BizTalk Services

Endpoint management

Yes

Only powershell

View message tracking

Yes

Basic

Deployment portal

Yes

Only powershell, Visual Studio

Auditing of operations

Partial

Partial

Health dashboard

Yes

No

Isolation of processes

Yes (hosts)

No, single tenant

Hierarchy of artifacts

Yes (applications)

No

Trading partner management & EDI

The TPM portal of WABS is really very nice and much friendlier than the BizTalk admin console of BizTalk.  The biggest issue with EDI is the fact that there is no possibility to extend and customize the EDI bridge…

 

BizTalk Server

BizTalk Services

Trading partner management

Yes (Biztalk Admin)

Yes (TPM Portal)

EDI extensibility

Yes

No (only with bridge as destination)

Extensibility

Luckily the product team did good efforts to add extensibility and the usability of custom bridge components should still be evolved well.

 

BizTalk Server

BizTalk Services

Custom pipeline components

Yes

Yes

Custom functoids

Yes

Yes

Custom adapters

Yes

Only outbound WCF

Custom business rules components

Yes

No

Custom workflow components

Yes

No

Security

 

BizTalk Server

BizTalk Services

Role based security in management portal

Yes

No

Endpoint security

Extensive support

Only ACS & FTP security

Added value services

This is really where BizTalk Server leads, compared to WABS.  And for most real solutions, these services are often needed.

 

BizTalk Server

BizTalk Services

Workflow

Yes (orchestrations)

No

Business Rules

Yes

No

Business Activity Monitoring

Yes

No

RFID

Yes

No

UDDI

Yes

No

Categories: BizTalk
written by: Sam Vanhoutte

Posted on Thursday, May 4, 2017 1:40 PM

Toon Vanhoutte by Toon Vanhoutte

Recently, the product team released a first feature pack for BizTalk Server 2016. Via this way, Microsoft aims to provide more agility into the release model of BizTalk Server. The feature pack contains a lot of interesting features, of which the brand new Management & Operational API is an important one. Let's have a look at what's included!

The documentation of the Management API can be found here.  In short: almost everything you can access in the BizTalk Administration Console is now available in the BizTalk Management API.  The API is very well documented with Swagger, so it's pretty much self-explaining.  

What is included?

A complete list of available operations can be found here.

Deployment

There are new opportunities on the deployment side. Here are some ideas that popped into my mind:

  • Dynamically create ports. Some messaging solutions are very generic. Adding new parties is sometimes just a matter of creating a new set of receive and send ports. This can now be done through this Management API, so you don't need to do the plumbing yourself anymore.

  • Update tracking settings. We all know it quite difficult to keep your tracking settings consistent through all applications and binding files. The REST API can now be leveraged to change the tracking settings on the fly to their desired state.

Runtime

Also the runtime processing might benefit from this new functionality. Some scenarios:

  • Start and stop processes on demand. In situations that the business wants to take control on when certain processes should be active, you can start/stop receive/send ports on demand. Just a small UI on top of the Management API, including the appropriate security measures, and you're good to go!

  • Maintenance windows. BizTalk is in the middle of your application landscape. Deployments on backend applications, can have a serious impact on running integrations. That's why stopping certain ports during maintenance windows is a good approach. This can now be easily automated or controlled by non-BizTalk experts.

Monitoring

Most new opportunities reside on the monitoring side. A couple of potential use cases:

  • Simplified and short-lived BAM. It's possible to create some simple reports with basic statistics of your BizTalk environment. You can leverage the Management API or the Operational OData Service. You can easily visualize the number of messages per port and for example the number of suspended instances. All of this is built on top of the data in your MessageBox and DTA database, so there's no long term reporting out-of-the-box.

  • Troubleshooting. There are very easy-to-use operations available to get a list of services instances with a specific status. In that way, you can easily create a dashboard that gives an overview of all instances that require intervention. Suspended instances can be resumed and terminated through the Management API, without the need to access your BizTalk Server.

This is an example of the basic Power BI reports that are shipped with this feature pack.

What is not included?

This brand new BizTalk Management API is quite complete, very excited about the result! As always, I looked at it with a critical mindset and tried to identify missing elements that would enable even more additional value. Here are some aspects that are currently not exposed by the API, but would be handy in future releases:

  • Host Instances: it would be great to have the opportunity to also check the state of the host instances and to even start / stop / restart them. Currently, only a GET operation on the hosts is available.

  • Tracked Context Properties: I'm quite fond of these, as they enable you to search for particular message events, based on functional search criteria (e.g. OrderId, Domain…). Would be a nice addition to this API!  You can vote here.

  • Real deployment: first I thought that the new deployment feature was built on top of this API, but that was wrong. The API exposes functionality to create and manage ports, but no real option to update / deploy a schema, pipeline, orchestration or map. Could be nice to have, but on the other hand, we have a new deployment feature of which we need to take advantage of!

  • Business Activity Monitoring: I really like to idea of the Operational OData Service, which smoothly integrates with Power BI. Would be great to have a similar and generic approach for BAM, so we can easily consume the business data without creating custom dashboards. The old BAM portal is really no option anymore nowadays. You can vote here.

Conclusion!

Very happy to see more commitment from Microsoft towards BizTalk Server. This emphasises their "better together" integration vision on BizTalk Server and Logic Apps! Check out the BizTalk User Voice page if you want to influence the BizTalk roadmap!

The exposure of BizTalk as a REST API opens up a new range of great opportunities. Don't forget to apply the required security measures when exposing this API! By introducing this API, the need for auditing all activity becomes even more important!

Thanks BizTalk for this great addition! Thank you for reading!

Cheers,
Toon

Categories: BizTalk
written by: Toon Vanhoutte

Posted on Wednesday, May 3, 2017 5:06 PM

Toon Vanhoutte by Toon Vanhoutte

Recently, the product team released a first feature pack for BizTalk Server 2016. Via this way, Microsoft aims to provide more agility into the release model of BizTalk Server. The feature pack contains a lot of new and interesting features, of which the new scheduling capabilities is an important one. Let's have a look at what's included!

The documentation of this scheduling feature can be found on MSDN.

What is included?

Support for time zones

The times provided within the schedule tab of receive locations are now accompanied by a time zone. This ensures your solution is not depending anymore on the local computer settings. There's also a checkbox to automatically adjust for daylight saving time.

This is a small, but handy addition to the product! It avoids unpleasant surprises when rolling out your BizTalk solutions throughout multiple environments or even multiple customers!

Service window recurrence

The configuration of service windows is now a lot more advanced. You have multiple recurrence options available:

  • Daily: used to run the receive location every x number of days
  • Weekly: used to run the receive location on specific days of the week
  • Monthly: used to run the receive location on specific dates or specific days of the month

Up till now, I didn't use the service window that much. These new capabilities allow some new scenarios. As an example, this would come in handy to schedule the release of batch messages on a specific time of the day, which is often required in EDI scenarios!

What is not included?

This is not a replacement for the BizTalk Scheduled Task Adapter, which is a great community adapter! There is a fundamental difference between an advanced service window configuration and the Scheduled Task Adapter. A service window configures the time on which a receive locations is active, whereas the Scheduled Task Adapter executes a pre-defined task on the configured recurrence cadence.

For the following scenarios, we still need the Scheduled Task Adapter:

  • Send a specific message every x seconds / minutes.
  • Trigger a process every x seconds / minutes.
  • Poll a rest endpoint every x seconds / minutes. Read more about it here.

Conclusion!

Very happy to see more commitment from Microsoft towards BizTalk Server. This emphasises their "better together" integration vision on BizTalk Server and Logic Apps! Check out the BizTalk User Voice page if you want to influence the BizTalk roadmap!

These new scheduling capabilities are a nice addition to BizTalk's toolbelt! In future feature packs, I hope to see similar capabilities as the Scheduled Task Adapter. Many customers are still reluctant to use community adapters, so a supported adapter would be very nice! You can vote here!

Thanks for reading!
Toon

Categories: BizTalk
written by: Toon Vanhoutte

Posted on Tuesday, February 21, 2017 2:38 PM

Pieter Vandenheede by Pieter Vandenheede

Dive into BizTalk 2016 with this webinar, describing the new features on BizTalk 2016.

Let’s dive into the new BizTalk Server 2016 and summarize its enhancements and newest features. Learn how BizTalk 2016 allows a much easier integration towards the cloud. BizTalk 2016 also supports for high availability both on premises and on Microsoft Azure with SQL Server AlwaysOn. You will hear about the platform upgrades and various updates around BizTalk tooling, operations and monitoring.

To conclude, your host Pieter will help you find an answer to the key question: whether or not you should upgrade to BizTalk 2016.

Watch the webinar below:

If you have any questions, don't hesitate to leave a comment below.

Cheers,
Pieter

Categories: BizTalk
written by: Pieter Vandenheede