BizTalk Adapter Pack – SAP Binding ReceiveTimeout

BizTalk Adapter Pack – SAP Binding ReceiveTimeout

 

One of the most important configurations to make inside a SAP Receive location is the “receiveTimeout” property.  The documentation describes this property as:

“Specifies the WCF message receive timeout. Essentially, this means the maximum amount of time the adapter waits for an inbound message. The default is 10 minutes.

Important

For inbound operations such as receiving IDOCs, we recommend setting the timeout to the maximum possible value, which is 24.20:31:23.6470000 (24 days). When using the adapter with BizTalk Server, setting the timeout to a large value does not impact the functionality of the adapter.”

The default value(10 minutes), is too short of a period for BizTalk to stop listening for messages from SAP.  For instance, if your organization has a weekly back up scheduled for SAP, it will likely take longer than 10 minutes.  The documentation indicates that there is no impact to using a large number so I am not sure why the default is only 10 minutes.

 

image

 

Just to give a practical example of what you can expect when SAP goes down (either planned or unplanned) from a BizTalk perspective.

SAP going down

Event Type:        Warning

Event Source:    BizTalk Server 2009

Event Category:                (1)

Event ID:              5740

Date:                     3/13/2XXX

Time:                     10:01:31 PM

User:                     N/A

Computer:          SERVER

Description:

The adapter "WCF-Custom" raised an error message. Details "The WCF service host at address sap://CLIENT=XXX;LANG=EN;@a/SAPServer/00?ListenerGwServ=SAPGateWay00&ListenerGwHost=SAPServer&ListenerProgramId=IDOC&RfcSdkTrace=False&AbapDebug=False has faulted and as a result no more messages can be received on the corresponding receive location. To fix the issue, BizTalk Server will automatically attempt to restart the service host.".

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type:        Warning

Event Source:    BizTalk Server 2009

Event Category:                (1)

Event ID:              5740

Date:                     3/13/2XXX

Time:                     10:01:31 PM

User:                     N/A

Computer:          SERVER

Description:

The adapter "WCF-Custom" raised an error message. Details "Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_FAILURE. AdapterErrorMessage=An exception has occurred on the listener while executing RfcWaitForRequest..

   at Microsoft.ServiceModel.Channels.Common.Design.AdapterAsyncResult.End()

   at Microsoft.ServiceModel.Channels.Common.Channels.AdapterReplyChannel.EndTryReceiveRequest(IAsyncResult result, RequestContext& requestContext)

   at Microsoft.Adapters.Internal.LayeredChannelBindingElement.LayeredInboundChannel`1.System.ServiceModel.Channels.IReplyChannel.EndTryReceiveRequest(IAsyncResult result, RequestContext& context)

   at System.ServiceModel.Dispatcher.ReplyChannelBinder.EndTryReceive(IAsyncResult result, RequestContext& requestContext)

   at System.ServiceModel.Dispatcher.ErrorHandlingReceiver.EndTryReceive(IAsyncResult result, RequestContext& requestContext)".

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

 

Event Type:        Warning

Event Source:    BizTalk Server 2009

Event Category:                (1)

Event ID:              5740

Date:                     3/13/2XXX

Time:                     10:01:32 PM

User:                     N/A

Computer:          SERVER

Description:

The adapter "WCF-Custom" raised an error message. Details "The faulted WCF service host at address sap://CLIENT=XXX;LANG=EN;@a/SAPServer/00?ListenerGwServ=SAPGateWay00&ListenerGwHost=SAPServer&ListenerProgramId=IDOC&RfcSdkTrace=False&AbapDebug=False could not be restarted, and as a result no messages can be received on the corresponding receive location. BizTalk Server will continue trying to start the service host until it succeeds or the receive location is disabled.

To fix the problem, you may choose to:

1. Use the error information given to fix the problem.

2. Restart the receive location.

3. Keep waiting for BizTalk to recycle the service host. Another event will notify if the service host is successfully started.

SAP coming back up

Event Type:        Information

Event Source:    BizTalk Server 2009

Event Category:                (1)

Event ID:              8112

Date:                     3/13/2XXX

Time:                     11:03:13 PM

User:                     N/A

Computer:          SERVER

Description:

The WCF service host at address sap://CLIENT=XXX;LANG=EN;@a/SAPServer/00?ListenerGwServ=SAPGateWay00&ListenerGwHost=SAPServer&ListenerProgramId=IDOC&RfcSdkTrace=False&AbapDebug=False was successfully restarted, therefore the associated receive location can now receive messages.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

 

You are now able to receive messages from SAP without any intervention.  Had we not set an appropriate ReceiveTimeout, the receive location would have still be down when SAP tried to push this IDoc to our system.

image

 

You never want your middleware to be the cause of an outage so it is important to understand when your dependant servers/services have scheduled maintenance so that you can ensure that your application can sustain this downtime.  Configuring the ReceiveTimeout to an appropriate value will reduce the chance that BizTalk will be down due to someone else’s maintenance window.

BizTalk Adapter Pack 2.0 – SAP Adapter IDoc Schema Versioning Part 2

BizTalk Adapter Pack 2.0 – SAP Adapter IDoc Schema Versioning Part 2

In my first post, I discussed how the BizTalk Adapter pack Consume Adapter Service wizard tightly couples the IDoc schema version with the version of SAP that you used to generate the schema with.  The goal of this post is to discover how you can avoid this tight coupling and hopefully survive an SAP upgrade.  I know the organization that I work for would not be pleased with having to update all of our IDoc schemas when we do our next SAP Upgrade just because the version of SAP has been incremented.

When the BizTalk Adapter Pack came out I was pretty excited that I could throw away my Flat File schemas and pipelines.  While true, it comes at a cost.  When using the XML Receive pipeline with the new Adapter, the Adapter will use data in the SAP Control record to determine what version of the message you retrieving from SAP and will assign a namespace to your message, that contains SAP version information, before depositing it in the message box. If have not changed your SAP version since generating your IDocs you are in business.  If you have upgraded your SAP system or have generated the wrong schemas for your SAP version then you will be in a lot of pain. 

To get around this tight coupling issue, you can revert back to the old style of IDoc processing which involves flat files and pipelines.  Now there is nothing really wrong with this model, but it does require a few extra steps and is not as “clean” a solution as using the XML Receive pipeline.

I will now take you through how you generate a flat file schema that can be used to process different versions of the same IDoc.  When I say different schemas this means that the version, and therefore namespace, are different but structurally the documents are the same.  Note that I will not go through all steps required to generate an IDoc schema, only those that are important to generate a Flat File schema.  To see a more comprehensive walk through of generating an IDoc schema, please see my Webcast.

 

  • When using Consume Adapter Service wizard, ensure that “GenerateFlatFileCompatible” is set to true.

image

When you set the GenerateFlatFileCompatible property to true, you will now see the flat file specific data within the Schema specification.

image

Without setting GenerateFlatFileCompatible ,  the schema will not contain this flat file information.

image

image

  • You also want to indicate the “ReceiveIDocFormat” will be a String.  You will find out why this is important later on in this post.

image

  • Once the schemas have been imported into Visual Studio, enable “Flat File Extensions” to the “core schema”.  When using the BizTalk Adapter Pack Consume Adapter Service wizard you will generate more than 1 schema unlike the old .Net Connector version where you would always only generate 1 schema.  By “core schema” I mean the one that contains the “meat” of your schema, not one that contains the shell(all of the imported schemas) or any of the base type schemas.

image

  • You will now need to create a Receive Pipeline and add a Flat File disassembler

PipelineComponentDesigner

  • Add your “shell” schema to the document schema property

image

  • Build and Deploy your application
  • When configuring your SAP Receive location you will want to specify your Receive Pipeline as opposed to XML Receive

image

  • On the Binding tab, set the “ReceiveIdocFormat” to String

image

  • On the Messages tab, provide an XPath expression that will extract the flat file data so it can be disassembled by the Receive Pipeline.  The XPath expression that I used is:

    /*[local-name()=’ReceiveIdoc’]/*[local-name()=’idocData’]

    The adapter is essentially wrapping this flat file in XML tags so that it can make it through the adapter stack as an XML message. 

    Also ensure the “Node encoding” is set to String as the default is “XML”

image

  • Start your application and you are good to go

 

  • Up until this point, I have not modified the namespace of my schema and everything worked well as expected

image 

 

  • However, the purpose of this post is to demonstrate how we can break away from the default namespaces that are generated by the adapter.

image

  • Since I have redeployed the application, the message subscription have also been updated:

 image

  • Start your application up and it should function with this new namespace and therefore subscription.

 

  • The next test is to generate a different version of an SAP IDoc and ensure receiving a different version of the IDoc does not break our application.  If you recall from Post 1 we received an error in this situation.  From the Consume Adapter Service wizard, I am deliberately going to generate a schema that has a DOCREL  greater than my current SAP version.

image

  • My subscription is updated and is looking for a “710” IDoc where as SAP is going to generate a
    “700” IDoc

image

  • I received, processed and delivered the message downstream without issue

image

  • Even though SAP, populated the Control record with DOCREL = 700, I am able to process this message because this DOCREL is not being used to derive the target namespace like it is when you use the XML Receive pipeline.  This is really where the value of the Flat file pipeline comes in as it will use the namespace in the schema that is configured inside the pipeline instead of having the Adapter generate a namespace automatically.   This also works as the structure of the 700 IDoc has not changed in the 710 IDoc.  If the structure of the IDoc changes with the version number then you have no other option than to regenerate your schemas.

image

 Gotcha!

So everything is fine and dandy until you try to deploy another IDoc with the same Program Id/Partner Profile.  There is bug with the BizTalk Adapter Pack that prevents you from deploying multiple IDoc Flat File schemas with the same Program ID.  Look for a workaround with my next post in this series.  I should be able to turn that post around quicker than this one.

Job @ Breeze: BizTalk /SharePoint specialist!

Hi guys – Breeze is looking for talent that can hit the ground running in BizTalk
and/or SharePoint.

Being a training company we’ll skill you up further and you’ll be working on a vast
array of cutting edge technologies.

Ideally you must be Sydney based and full time preferred.

If you’re up then drop Nicki a line – n i c k i p @ <no spam> breeze (dot) net

Happy travels all,

Mick.

BizTalk: Dynamic SMTP Port: Unknown Error Description

Today I investigated one strange error working with Dynamic SMTP Port.
Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5754
Date: ********
Time: ********AM
User: N/A
Computer: ********
Description:
A message sent to adapter “SMTP” on send port “*********” with URI “mailto:********.com” is suspended.
Error details: Unknown Error Description
MessageId: {********}
InstanceID: {********}
My code was pretty simple and the source of the error was hidden somewhere inside it.
msg_MyMessage(SMTP.CC) = var_CC;
msg_MyMessage(SMTP.From) = var_From;
msg_MyMessage(SMTP.Subject) = var_Subject;
msg_MyMessage(SMTP.EmailBodyText) = var_Message;// #1
msg_MyMessage(SMTP.SMTPHost) = ” localhost “;
msg_MyMessage(SMTP.SMTPAuthenticate) = 0;
When I added line #2, this frustrating error disappeared.
msg_MyMessage(SMTP.EmailBodyTextCharset) = “UTF-8”; // #2
Conclusion:
If we use the SMTP.EmailBodyText property, we must set up the
SMTP.EmailBodyTextCharset property.

To me it looks like a bug in BizTalk. [Maybe it is “by design”, but in this case give us a useful error text!!!]

And don’t ask me how much time I’ve spent with this investigation.

CODit speaking at the BizTalk User Group Sweden

On 16th March, CODit is speaking at the BizTalk User Group in Stockholm (Sweden).

CODit is presenting an introduction to Host Integration Server, the secret gem of Microsoft 🙂

You can subscribe here: http://swebug20100316-widget.eventbrite.com/

Content of the presentation:

Session: Introduction to Microsoft Host Integration Server
Speakers: Peter Borremans & Sam Vanhoutte

Over the years, a lot of companies invested in IBM mainframe (zSeries) or midrange (iSeries) systems. The mainframe architecture is not compatible with nowadays standards and architectures. Rewriting applications is not always feasible and desired. These applications are often very large systems with high reliability and performance. If possible
people’s skills must be reused. This leads to the need of integrating with existing host systems. Microsoft created Host Integration Server (HIS) to integrate with host systems.
This session will cover all important components of HIS and how Mainframe functionality is exposed to newer technologies:

Network integration

As mentioned earlier, IBM host systems (most of the time mainframe systems) use a proprietary network architecture.
HIS network integration will allow other systems to connect to those networks and expose functionality higher up in the stack (MQ, Applications, Data).

Data integration

HIS data integration will allow Microsoft systems to access data stored in DB2 databases or in VSAM files.
This is either done with by using .NET data providers (DB2 or VSAM) or by using BTS adapters (DB2 or VSAM)

Application integration

HIS application integration will allow Microsoft systems to interface with IBM host applications as CICS transactions (Transaction Integrator) or IMS.
Application integration is without any doubt one of the most powerful features of HIS.

Messaging integration

By using HIS, Microsoft BizTalk server can communicate with MQSeries on any other platform. HIS provides a WebSphere MQSeries client-based adapter. This adapter does not require a MQSeries installation on a Windows Server box. The WebSphere MQSeries client-based adapter allows direct access to MQSeries on host systems.

ASP.NET MVC 2 Released

I’m happy to announce that the final release of ASP.NET MVC 2 is now available for VS 2008/Visual Web Developer 2008 Express with ASP.NET 3.5.  You can download and install it from the following locations:

The final release of VS 2010 and Visual Web Developer 2010 will have ASP.NET MVC 2 built-in – so you won’t need an additional install in order to use ASP.NET MVC 2 with them. 

ASP.NET MVC 2

We shipped ASP.NET MVC 1 a little less than a year ago.  Since then, almost 1 million developers have downloaded and used the final release, and its popularity has steadily grown month over month.

ASP.NET MVC 2 is the next significant update of ASP.NET MVC. It is a compatible update to ASP.NET MVC 1 – so all the knowledge, skills, code, and extensions you already have with ASP.NET MVC continue to work and apply going forward. Like the first release, we are also shipping the source code for ASP.NET MVC 2 under an OSI-compliant open-source license.

ASP.NET MVC 2 can be installed side-by-side with ASP.NET MVC 1 (meaning you can have some apps built with V1 and others built with V2 on the same machine).  We have instructions on how to update your existing ASP.NET MVC 1 apps to use ASP.NET MVC 2 using VS 2008 here.  Note that VS 2010 has an automated upgrade wizard that can automatically migrate your existing ASP.NET MVC 1 applications to ASP.NET MVC 2 for you.

ASP.NET MVC 2 Features

ASP.NET MVC 2 adds a bunch of new capabilities and features.  I’ve started a blog series about some of the new features, and will be covering them in more depth in the weeks ahead.  Some of the new features and capabilities include:

You can learn more about these features in the “What’s New in ASP.NET MVC 2” document on the www.asp.net/mvc web-site. 

We are going to be posting a lot of new tutorials and videos shortly on www.asp.net/mvc that cover all the features in ASP.NET MVC 2 release.  We will also post an updated end-to-end tutorial built entirely with ASP.NET MVC 2 (much like the NerdDinner tutorial that I wrote that covers ASP.NET MVC 1). 

Summary

The ASP.NET MVC team delivered regular V2 preview releases over the last year to get feedback on the feature set.  I’d like to say a big thank you to everyone who tried out the previews and sent us suggestions/feedback/bug reports. 

We hope you like the final release!

Scott

Now Available: The Windows Azure platform AppFabric LABS Environment

Today the AppFabric team has released the AppFabric LABS environment. This is a new environment which the team will use to showcase some early bits and get feedback from the community. Usage for this environment will not be billed.


 


AppFabric Labs provide a way for customers to test out and play with experimental AppFabric technologies. These are upcoming capabilities that excite us, and we want to get your feedback on them as soon as possible. As a result, there is no support or SLA associated with the LABS environment, but in return you will be able to preview the future of AppFabric while helping us shape it. Though similar to a Community Technology Preview, LABS technologies may occasionally be even farther away from commercial availability.


 


In this release of the LABS environment, we’re shipping two features:


1.     Silverlight support: we’ve added the ability for Silverlight clients to make cross-domain calls to the Service Bus and Access Control Services.


2.     Multicast with Message Buffers: we’ve added the ability for Message Buffers to attach to a multicast group. A message sent to the multicast group is delivered to every Message Buffer that is attached to it.


To get started:


1.     Go to https://portal.appfabriclabs.com/,


2.     Sign up using your Live ID,


3.     Create your LABS project, and


4.     Download LABS samples from here to learn more about these new features.


We hope you enjoy working with these Labs features as much as we have enjoyed making them available to you.


 


Thanks,


 


The Windows Azure platform AppFabric Team

BizTalk Performance and DNS

BizTalk Performance and DNS

We recently solved a performance problem that had been plaguing us for quite some time on one of our Test/QA BizTalk Application servers. Even if you aren’t experiencing theproblem to the full extent that we were,I’ll bet I can improve your performance too – want to try? Here’s a brief summary of our problem:
We have […]