Life is a journey

Who Dares Wins
posts - 26, comments - 2, trackbacks - 0, articles - 0
  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理

2012年2月8日

Error:

The transaction log for database ‘BizTalkMsgBoxDb’ is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases (.Net SqlClient Data Provider)

 

Solution:

sp_helpdb ‘BizTalkMsgBoxDb’

ALTER DATABASE BiztalkMsgBoxDb

SET RECOVERY SIMPLE;

GO

DBCC SHRINKFILE (BiztalkMsgBoxDb_log, 1);

GO

sp_helpdb ‘BizTalkMsgBoxDb’

GO

ALTER DATABASE BiztalkMsgBoxDb

SET RECOVERY FULL

GO

posted @ 2012-02-08 18:13 zhaobin 阅读(5) 评论(0) 编辑

2012年1月26日

Original from: http://www.west-wind.com/weblog/posts/2004/Oct/11/Fiddler-and-Application-Proxy-setup

 

I’ve been working on a couple of apps that do extensive HTTP and Web Service access over the last few days and Fiddler has been a huge help in debugging some odd problems I’ve been having. This ASP.NET Web app has both .NET and FoxPro clients talking to it and checking out the traffic and difference of the client communication was driving me nuts for a while.

One tool I continue to use all the time when working on any sort of distributed application is Fiddler. If you haven’t used Fiddler before, run, don’t walk and download this awesome little proxy that lets you easily see the content of requests made over HTTP over the network. It works great, but keep in mind it doesn’t work for Localhost (it might with a loopback adapter though – haven’t tried it) or over HTTPS in which case you have to remember to step it down to HTTP for debugging. It’s great for debugging problems in distributed applications, but is also great if you need to debug Web based applications for things like Cookies, custom headers etc. What makes Fiddler nice is that shows both content and headers and lets you easily view all of this diverse content in a somewhat intuitive way – for example, images can be previewed, XML can be viewed as a node list and you can apply viewers to any content sent or returned. If you’re building any kind of Web application sooner or later this functionality will come in REAL handy.

Fiddler works by setting up a proxy on port 8888 and then re-routing Web requests through it. It does this by basically changing IE’s proxy settings on the fly.

If you’re using a .NET client though you will have to configure the client in order for Fiddler to be able to see the communication. By default the .NET HttpWebRequest uses direct connections – meaning it doesn’t check or use for any proxies in the system and will thus not be picked up by Fiddler once it’s started.

If you’re using .NET you have to tell the .NET HTTP clients to use a proxy object. .NET allows you to custom configure a proxy using the Proxy property. The Proxy object is available both on lower level objects like HttpWebRequest as well as on higher level objects like a Web Services proxy.

You can configure a Proxy object manually by creating a new WebProxy object:

WebRequest.Proxy = new WebProxy("127.0.0.1:8888",true);

or probably the better choice: You can use the default proxy which reads the Internet Explorer settings for the current user:

WebRequest.Proxy = WebProxy.GetDefaultProxy();

You can apply the same logic to a Web Service client’s Proxy property as well.

If you’re using the MSSOAP Toolkit, you also have to do some custom configuration. You also need to set the Proxy server using the appropriate ConnectorProperty:

THISFORM.oNet = CREATEOBJECT("MSSOAP.SoapClient30")

THISFORM.oNet.MSSOAPInit(lcWSDLURL)

thisform.oNet.ConnectorProperty("ProxyServer")="<CURRENT_USER>"

loNL = thisform.oNet.LoadAuthors("");

If you’re using WinInet you can use a Connection type in Interopen:

hInetConnection=;

InternetOpen(THIS.cUserAgent,;

THIS.nhttpconnecttype,;

THIS.chttpproxyname,THIS.chttpproxybypass,0)

Where the ConnectType is 0 for IE Configuration, 3 for custom proxy, and 1 for direct access. Generally you’ll want to use 0. If you’re using wwHTTP in Visual FoxPro, nHttpConnectType is defaulted to 0 which maps to this WinInet setting.

posted @ 2012-01-26 10:39 zhaobin 阅读(7) 评论(0) 编辑

2011年5月18日

Thought this might be of interest to a few BizTalk developers out there.

It's quite common practice to use Distinguished Fields in orchestrations, to get/set the value of an element or attribute.

However, if the element you're trying to set/get doesn't exist, then this poses a few problems.

Setting a Distinguished Field
If the element/attribute doesn't exist in the target message, then you'll get an exception, no questions asked – there's no way around this.
Under the covers, the SetDistinguishedField method is called to set the value – and it doesn't check if the element/attribute exists first.
The same thing happens if you use the xpath() function to set a value, and the element/attribute doesn't existBizTalk isn't about to modify your message and add the element/attribute for you.

In this case, it's your responsibility to check that the element/attribute exists.
If it's a message that you create, then you have to make sure that the element/attribute is created (do this in a map by mapping an empty Value Mapping functoid to it, or setting the Value property to "<empty>").

Getting a Distinguished Field
This is more interesting.
In a nutshell, if the Distinguished Field is of type string (or any other nullable type) then you'll get null.
Otherwise, you'll get an InvalidCastException.

The reason for this is in the underlying code.

The orchestration calls XSDPart.GetDistinguishedField to get your value:
public override object GetDistinguishedField(string dottedPath)
{
    XsdDistinguishedFieldDefinition dFDef = (XsdDistinguishedFieldDefinition) base.GetDFDef(dottedPath);
    object val = base._getXPath(dFDef.XPath, dFDef.IsDynamic);
    if (val == null)
    {
        return null;
    }
    if (val.GetType() != dFDef.FieldType)
    {
        val = XmlHelpers.ChangeType(val, dFDef.FieldType);
    }
    return val;
}

This method will return null if the element/attribute doesn't exist otherwise it will attempt to convert (cast) the value to the appropriate type.

However, the InvalidCastException arises from your orchestration.
Let's assume you had a Distinguished Field called isSuccessful which is of type boolean.

When you write something like
if (Response.isSuccessful)
in an expression shape, the code generated is this:

if (!((bool) __ctx2__.__Response.part.GetDistinguishedField("isSuccessful")))

Ahah! The orchestration does an explicit cast of the Distinguished Field value to a bool.
And an explicit cast of null to a bool will raise an InvalidCastException.

However, an explicit cast of null to a string is fine.

So if you had a Distinguished Field called employeeName of type string, then the same code would be:
if (!((string) __ctx2__.__Response.part.GetDistinguishedField("employeeName")))

And no exception would be raised.

Conclusion
If you're using Distinguished Fields with types other than string, and the element/attribute you're referring to is optional then you must check that the element/attribute exists before attempting to set/get a value.

In most cases, you'd do this by using the xpath() function in an orchestration
(e.g. getting a count of the element/attribute, and checking that count > 0)

Just FYI....!

 

Original from:http://www.bizbert.com/bizbert/2007/11/15/Distinguished+Fields+And+Optional+Elements.aspx

posted @ 2011-05-18 18:03 zhaobin 阅读(22) 评论(0) 编辑

2011年3月10日

Correlations form a fundamental concept of BizTalk 2004. They specify how individual messages are related, and are used to tell BizTalk how to process them.

 

An advise from the heart: take your time to understand the basics of correlations in BizTalk. You will encounter many aspects of correlations when your developments are becoming more complex. With some basic knowledge, you will be able to design a solution that can indeed be realized in BizTalk. When you fail to see the intricacies of correlations, all of your attempts might result in serious error, forcing you into a new attempt for a solution.

 

First, a short explanation on how the “messaging engine“ of BizTalk works. When you deploy a project, the orchestrations will become available in the runtime environment. When the deployed orchestration is started, it subscribes to messages of a designated type (message type) delivered at a designated location (port). That means that, apart from taking the subscription, nothing really happens until a message arrives. The messaging engine receives the message, and determines the type. Based on this, it fires up an instance of the orchestration that subscribed to it.

So, the subscription information is essential for locating an orchestration that matches the message type when a message comes in. This information is contained in the receive shape and the connected port in an orchestration. The receive shape provides the message type the orchestration expects, the port tells (after binding) where and how messages of this type are expected.

 

Now, what happens when I require more than one receive shape in my orchestration? Can I receive messages of different types in a single orchestration? What about multiple instances of the same message type? How do we specify a sequence of actions?

For all questions, there is a proper solution in BizTalk. Not all answers will be discussed here. When you plan to use more than one receive shapes in an orchestration, you will have to specify the behavior of your orchestration for incoming messages on each receive shape. In other words: when a message comes in and it can be related to a specific orchestration, the messaging engine should be able to tell whether it should fire up a new instance of the orchestration for this message or it should pass this message as input to an already running orchestration instance (and: which one of the running orchestration instances). This is done using correlations and related settings of the receive shapes.

 

[example]

Invoice data is sent from system A to system B. The invoice data is sent as soon as it is created in system A. Another user of system A has to check the invoice and approve it. After approval, system A sends approval data to system B. In between systems A and B sits BizTalk. The idea is that BizTalk collects both pieces of information on a single invoice before sending it to system B. We can assume that the invoice data is always sent before the approval. All invoices (invoice data and invoice approval data) are uniquely identified by an invoice number.

The orchestration to do this contains two receive shapes. The first one receives the invoice message. The second one receives the invoice approval message. Only after both have been received, a message is sent out to system B. The receive shape for the invoice message has the “Activate“ property set to true. This means that any invoice message received will cause a new instance of the orchestration to be started. The receive shape for the invoice approval message has the “Activate“ property set to false. This means that the invoice approval message will only be accepted by already running instances of the orchestration. This looks great, but still something is missing. What if invoices 1234 and 1235 are created (and sent to BizTalk), and only approved of later? Two instances of the orchestration are running (one for 1234 and one for 1235) when the approval for 1235 comes in. BizTalk knows (from the “Activate“ property of the receive shape) that the approval should go into an already running orchestration instance. Which one? That is determined by a correlation set, relating the two receive shapes.

The receive shape for the invoice message is set to “initialize“ a correlation set for the invoice number. The receive shape for the invoice approval message is set to “follow“ a correlation set for the invoice number. How does this work? When a new invoice message comes in, a new orchestration is started, the invoice message is read, and the invoice number is taken out and associated with the orchestration instance. The orchestration instance is parked, waiting for the approval message (this is called “ dehydration“). When an invoice approval message comes in, it is also read. With the invoice number form the apprval message, the correct orchestration instance is looked up. This orchestration will proceed (after “rehydration“).

[end of example]

 

An overview of settings and components required to set up an orchestration using multiple receive shapes:

  • Promoted properties. In the schemas that define the message types you will be receiving, you can promote properties. This is done to make data (tag values) out of a message instance available in the message context, i.e. accessible to the environment for control. To set up a correlation, you need to promote properties from all schemas involved into a single property schema. The names of the promoted properties don't need to be equal, but ensure that there is exactly one entry in the property schema for each promoted property, no matter how different message types call this property.
  • Create a correlation type using the promoted property. See the “types“ section of the “orchestration view“ of the orchestration.
  • Create a correlation set using the correlation type.
  • For a simple correlation (like the example): determine which receive shape will be activating the orchestration. This will also be the receive shape initializing the correlation set (usually). The other receive shape(s) will be non-activating and will be “following“ the same correlation set.
  • After you have completed setting up the orchestration, check what BizTalk thinks about this by building the containing project. When you get error messages that point in he direction of multiple receive shapes, correlation sets and property schemas, you have probably created something that conflicts with the basic rule for using multiple receive shapes: BizTalk should always exactly know what to do when an instance of a message type is received. When it can not determine this (at compile time), it will not compile the project.

 

Please note: the example and the explanation of terms below describe a very simple correlation scenario, in which two messages are received in a fixed sequence. There are numerous other possibilities to combine multiple messages in a single orchestration. Please refer to documentation and other resources on the topic of “convoys“, as this is the way to solve the more complex problems.

posted @ 2011-03-10 11:59 zhaobin 阅读(34) 评论(2) 编辑

2011年3月4日

When a user tries to connect to a machine using Remote Desktop connection, they might come across this error message.

The terminal server has exceeded the maximum number of allowed connections

This is because Windows Server only allows two connections through RDP, and you’ve either got two people already logged on to that machine, or you’ve got disconnected sessions that still thinks they are active. If a user simply closes the remote desktop window when they’re finished, that user will still remain logged on, unless there is a time out configured in Terminal Services Configuration as follows

Terminal Services Configuration

Terminal Services Configuration

If the Session time out is not configured, or the logged on users are not available, you wont be able to logon to the machine. To overcome this limitation, follow the steps as below.

open a command prompt or type in the RUN prompt

mstsc /v:[00.00.00.00/SERVERNAME] /f -console

eg: mstsc /v:192.168.1.10 /f -console
mstsc /v:ADSURF /f -console

This will connect to the physical console session on the server (also known as “session zero”). You will then be prompted with the login box and provide the administrator details. Then you will be connected to the Console Session on the server. Now you can reset the disconnected user sessions from Terminal Services Manager. Please note that if you get disconnected from this console session, you will have to go physically to the machine.

More info on mstsc at Technet

UPDATE:
If you have Windows Vista with SP1 or Server 2008, use the following syntax:

mstsc /admin

If you use the old switch “/console”, it will just ignore that and proceed connecting. In Windows Server 2008, the /console switch doesn’t exist anymore because “session 0″ is a non-interactive session that is reserved for services. Difference between admin and console swtich are here.

Another workaround:

You can also query the sessions on the remote machine as an administrator of that machine. Open a command prompt as a domain administrator that the remote machine is set to or map a drive of that remote machine.

Then in the command prompt, type as below:

query session /server:servername

Replace servername with the remote machine name or IP address.

Now we have the information of all the users/sessions that are active/disconnected on the remote machine. We can now reset one of the session with the following command.

reset session [ID] /server:servername

Replace [ID] with the number from the prevoius output and servername with the remote machine name or IP address. This will reset the session and now you can login using Remote Desktop connection.

posted @ 2011-03-04 18:04 zhaobin 阅读(566) 评论(0) 编辑

2011年1月28日

摘要: Last week, Steve Jobs and Apple launched the new and eagerly anticipated iPad. Over the years I have admired Apple for their branding, product launches and product innovation.This post is a more personal glimpse at a much-respected and innovative thinker. I thought I’d share with you a speech by Ste阅读全文

posted @ 2011-01-28 16:15 zhaobin 阅读(13) 评论(0) 编辑

2011年1月27日

摘要: When using HTTP, SOAP or WCF send ports it can be incredibly useful to view the content of messages that are sent on the wire. This allows you to inspect the headers (SOAP or HTTP). Fiddler is a simple but fantastic tool to allow you to do this.By default, Fiddler will not trace any messages sent to阅读全文

posted @ 2011-01-27 14:02 zhaobin 阅读(15) 评论(0) 编辑

2010年12月9日

摘要: It is usually a very important task to clean up a BizTalk mseeage box during stress testing with large amount of messages. Below are the steps to clean up the message box in order to prepare for the new test.1. Stop all BizTalk services2. Type “iisreset” at command line to recycle IIS service3.Execu阅读全文

posted @ 2010-12-09 15:49 zhaobin 阅读(8) 评论(0) 编辑

2010年11月10日

摘要: A AARON(希伯来)启发的意思,AARON被描绘为不高但英俊的男人,诚实刻苦具有责任感,是个有效率个性沉靜的领导者。ABEL(希伯来)"呼吸"的意思,为ABELARD的简写,大部份的人认为ABEL是高大,强壮的运动员,能干,独立,又聪明。有些人则认为ABEL是瘦小,温顺的男孩。ABRAHAM原为希伯来文,意为"民族之父"。后来,它演变成"物之父"的意思。大多万数人將ABRAHAM形容为高大壮硕...阅读全文

posted @ 2010-11-10 15:56 zhaobin 阅读(44) 评论(0) 编辑

2010年11月9日

摘要: Installcd d:\cps\bin\backendinstallUtil Batch.Monitor.Service.exeUninstallcd d:\cps\bin\backendinstallUtil -u Batch.Monitor.Service.exe阅读全文

posted @ 2010-11-09 16:24 zhaobin 阅读(41) 评论(0) 编辑