November 11, 2019 Weekly Update on Microsoft Integration Platform & Azure iPaaS

November 11, 2019 Weekly Update on Microsoft Integration Platform & Azure iPaaS

Do you feel difficult to keep up to date on all the frequent updates and announcements in the Microsoft Integration platform and Azure iPaaS?

Integration weekly update can be your solution. It’s a weekly update on the topics related to Integration – enterprise integration, robust & scalable messaging capabilities and Citizen Integration capabilities empowered by Microsoft platform to deliver value to the business.

If you want to receive these updates weekly, then don’t forget to Subscribe!

 

Microsoft Announcements and Updates

 

Community Blog Posts

 

Video

 

Podcasts

 

How to get started with iPaaS design & development in Azure?

Feedback

Hope this would be helpful. Please feel free to reach out to me with your feedback and questions.

BizTalk Documenter: Unable to locate the help compiler executable while trying to generate the documentation

BizTalk Documenter: Unable to locate the help compiler executable while trying to generate the documentation

Without a doubt, BizTalk Documenter is my favorite documentation tool, and I do think that if each product had a tool like for the generation of technical documentation, it would be simpler to do, as the existing documentation significantly improved. I do miss this kind of tool for Azure Integration projects.

However,
each time I install this tool I always got the exact same problem:

Unable to locate the help compiler executable

BizTalk Documenter 2016 Unable to locate the help compiler executable

which I know well, and I know why since it was very well explained by Mitch Vanhelden in this blog post.

So, why this blog post?

Well, for two main reasons:

  • I’m
    always searching to find the link to the component I need to install;

    • Basically,
      this is just an easy personal reminder;
  • And
    second and most important, the link to the resource that Mitch point is
    obsolete and not working anymore;

Cause

Has Mitch explained in his blog post, the
reason for this is quite clear, the application can’t locate the help compiler
executable, either because:

  • it
    isn’t installed à most common situation
  • or
    it is also possible if you’re working on a 64-bit machine.

Solution

Make sure you have installed the HTML Help
Workshop compiler because this is the most common cause for this issue and if
not:

  • First, download and install this compiler that can be found here: HTML Help Workshop and Documentation;
  • And then install it, by executing the htmlhelp.exe file
  • On the HTML Help Workshop 1.3 screen, click Yes
install HTML Help Workshop compiler
  • On
    the HTML Help Workshop 1.3 Setup screen, click Yes
install HTML Help Workshop compiler
  • Specify
    the installation directory and then click OK
install HTML Help Workshop compiler
  • And
    finally, when the installation finish, click OK

After these steps, you should be able to
generate the BizTalk Server documentation form the tool. Otherwise, make sure
that the path to this help compiler is configured correctly in BizTalk
Documenter by:

  • Access
    to the installation path of BizTalk Documenter

    • By
      default: C:Program Files (x86)Microsoft ServicesBizTalk Documenter
  • Open
    Microsoft.Services.Tools.BiztalkDocumenter.exe.config file and validate
    and, if necessary, change the path for the HelpCompilerLocation key
    that needs to contain the correct path to the HTML Help Workshop compiler
    component.

The post BizTalk Documenter: Unable to locate the help compiler executable while trying to generate the documentation appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk WCF-SQL Error: Microsoft.ServiceModel.Channels.Common.MetadataException: Object [dbo].[ColumnName] of type StoredProcedure does not exist.

BizTalk WCF-SQL Error: Microsoft.ServiceModel.Channels.Common.MetadataException: Object [dbo].[ColumnName] of type StoredProcedure does not exist.

In the past, I wrote a blog post about a similar type of error: BizTalk WCF-SQL Error: Microsoft.ServiceModel.Channels.Common.MetadataException: Object [dbo].[StoredProcedureName] of type StoredProcedure does not exist. The difference for this new post is that instead of being the Stored Procedure name that is complaining it is now complaining about the Column name:

A message sent to adapter “WCF-Custom” on send port ” STAGING_SQL_WCF_SEND” with URI “mssql://SQL-SERVER-NAME//Database?” is suspended.
Error details: Microsoft.ServiceModel.Channels.Common.MetadataException: Object [dbo].[IdRecord] of type StoredProcedure does not exist

Server stack trace:
at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndRequest(IAsyncResult result)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at System.ServiceModel.Channels.IRequestChannel.EndRequest(IAsyncResult result)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)
MessageId: {0193EE6F-8DFF-4861-87FB-FC1C82ECF3AB}
InstanceID: {59E3F39A-BF24-4583-BEA9-78CED5B621F7}

Microsoft.ServiceModel.Channels.Common.MetadataException: Object [dbo].[ColumnName] of type StoredProcedure does not exist.

However, despite this error and despite the
fact that we were talking about the same server and same project of the previous
issue, one thing I was sure about: they were not related at all.

Cause

At a first glimpse, it seems that the stored
procedure does not include the column name: IdRecord, or that this field
was not passed to the stored procedure at all. So, this was my first point to validate,
however, quickly I realized that:

  • The
    stored procedure had that field;
  • And
    I was correctly passing that field to the stored procedure in the message;

Just to precaution, I double-check if that was
not related to security permission, and it was not also. So I went back to my some
conspiracy theories list that I described on my previous post:

  • You
    should regenerate schemas: no, never
  • or
    that may be a mismatch in the namespaces: I believe it could be a
    possibility, but no, since I was using the same scheme and it was working fine
  • that
    the “?” character that you normally find in the URI is causing this problem: also
    impossible in my case
    .
  • And
    my favorite is that you should give “sysadmin” rights to the service account
    that is running the host instance: never.

But the last one put me thinking: the
operation is not properly set
.

Because the last change I did was redesign the
solution that was performing composite operations with the SQL Adapter, in my
case I was sending multiple-rows to update in the same message.

And now I was doing a single operation.

And by doing that the WCF-SQL Adapter was throwing
this strange behavior.

Solution

The solution was quite simple. We just have to
change the Action CompositeOperation with the correct operation action mapping
as show bellow as an example:

<BtsActionMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Operation Name="SQLStatusUpdateOp" Action="TypedProcedure/dbo/sp_BTS_updateTransaction" />
</BtsActionMapping>

After doing this change, everything started
working perfectly again.

The post BizTalk WCF-SQL Error: Microsoft.ServiceModel.Channels.Common.MetadataException: Object [dbo].[ColumnName] of type StoredProcedure does not exist. appeared first on SANDRO PEREIRA BIZTALK BLOG.

November 04, 2019 Weekly Update on Microsoft Integration Platform & Azure iPaaS

November 04, 2019 Weekly Update on Microsoft Integration Platform & Azure iPaaS

Do you feel difficult to keep up to date on all the frequent updates and announcements in the Microsoft Integration platform and Azure iPaaS?

Integration weekly update can be your solution. It’s a weekly update on the topics related to Integration – enterprise integration, robust & scalable messaging capabilities and Citizen Integration capabilities empowered by Microsoft platform to deliver value to the business.

If you want to receive these updates weekly, then don’t forget to Subscribe!

 

Microsoft Announcements and Updates

Community Blog Posts

 

Video

 

Podcasts

 

How to get started with iPaaS design & development in Azure?

Feedback

Hope this would be helpful. Please feel free to reach out to me with your feedback and questions.

BizTalk Server: The transaction log for database ‘BizTalkMsgBoxDb’ is full due to ‘LOG_BACKUP’.

BizTalk Server: The transaction log for database ‘BizTalkMsgBoxDb’ is full due to ‘LOG_BACKUP’.

Recently a
friend of mine that is working with me in a project send me an email reporting
a quite curious issue that I found while accessing the BizTalk Server
Administration console in our development environment:

This operation failed while accessing at least one of the Message Bix databases. Some results might be omitted. (Microsoft.Biztalk.Administration.SnapIn)

Additional information:

The transaction log for database ‘BizTalkMsgBoxDb’ is full due to ‘LOG_BACKUP’. (Microsoft SQL Server, Error: 9002)

The transaction log for database ‘BizTalkMsgBoxDb’ is full due to ‘LOG_BACKUP’

Immediately I point out to the team that this issue
was related to lack of disk space.

Cause

The official cause of
this issue is that when the transaction log becomes full, SQL Server Database
Engine issues a 9002 error. The log can fill when the database is online, or in
recovery. If the log fills while the database is online, the database remains
online but can only be read, not updated.

And for us to know the exact cause for what is
preventing log truncation, we can use the log_reuse_wait and log_reuse_wait_desc
columns of the sys.database catalog view.

In our case, it was indeed a problem with disk
space and what happened was that the disk to where we were doing backup went out
of disk space, because we cannot do the backups the transaction log grow until
the point that disk (that contain the log file) also went out of disk space.

Solution

When you know the issue, the solution is quite easy. In this case, freeing disk space from both hard drives immediately solves the problem. Nevertheless, because the log file got quite big you should think of stopping your BizTalk Server environment and do maintenance in your databases in special reduce the size of the transaction log.

For that you should:

  • Perform
    a full back of your databases;
  • Stop
    all BizTalk Server services (host instances and enterprise Single Sign-on)
  • And
    run the following SQL Script
ALTER DATABASE BizTalkMsgBoxDb
SET RECOVERY SIMPLE;
GO

DBCC SHRINKFILE (BizTalkMsgBoxDb_log, 2048);
GO

ALTER DATABASE BiztalkMsgBoxDb
SET RECOVERY FULL
GO

  • Do
    about the same steps for other databases whose transaction logs are also quite large.

The post BizTalk Server: The transaction log for database ‘BizTalkMsgBoxDb’ is full due to ‘LOG_BACKUP’. appeared first on SANDRO PEREIRA BIZTALK BLOG.