[community-content]

I’ve heard of others have problems with EDI or maybe it was you posting some other messages about it…  I know very little on how EDI works inside BizTalk so I can’t help you much. 

 

You might have better luck with a custom property.  Just sure you set the context type to “Message Contact Value” rather than the default.  That will make a big difference.

 

This might help: http://www.biztalkgurus.com/blogs/biztalk/archive/2004/09/17/Working-with-Untyped-Messages-In-An-Orchestration-_1320_-Part-2.aspx

[community-content]

Got that !!!

Yeah, you are right, turns out I forgot to update generated web service project. the method name is the wrong one …

object[] invokeResults = this.Invoke("MethodName", invokeParams, inParam …

Thanks so much for your help, Thomas. Really appreciate it!
 

[community-content]

I don’t think it’s a bug.  I think it’s by design and probably for a good reason.

I remember my problem better now; I was getting routing failures like you and looked at the subscriptions.  My problem was the MethodName of the Server that was sending in the message.  It was using “SomethingElse” and was expecting CCValidateSrv (in your case). 

I think the subscription is set up this way to allow multiple Receive Ports to process many different methods (i.e. types of requests).  I fixed it by chancing the method name sent by the service. 

If you export an Orchestration as a Web Service, the Method Name is the Port Operation Name.  If you expose a schema as a web service, I’m not sure where it gets the method name.  I bet if you look at the WSDL of the service, you’ll see CCValidateSrv as the method name.  Maybe you are not consuming the WSDL correctly? 

In my case, the method name was set on the client side.

Oh, you might also want to look at my sample about Untyped Web Services.  I don't remember what I did to the Method Name…

Hope this helps.

[community-content]

Thanks for the reply. Although I am not using Wizard to create the receive port (in stead, I manually create a SOAP port and bind the orchestration), it turns out the same weird result. This problem becomes even critical when I tried to export the MSI and deploy to staging server, manually modify the binding property is not the final solution … A bug of BizTalk 2006?

[community-content]

I was first using the filename to track the message, (promoting the FILE.ReceivedFileName in a custom pipeline). This works fine with the file adapter but then I pick up the message with the EDI adapter the tracking is lost, which is not so strange because I guess that the EDI adapter uses a different property schema …

[community-content]

Thanks Stephen,

I guess that if Biztalk needs an exclusive lock that my bit of C++ code could no longer have the file open for writing?  I'm not sure how locking works with simple text file under windows as I'm an old mainframe f@rt.

Thanks again.

Yaz

[community-content]

Have you checked that the user running the SQL Adapter (i.e. the host) has access to SQL?  I’m guessing it’s a permissions problem.

[community-content]

It’s kind of funny to see this.  I was having the exact same problem a few days ago.  I got around it by doing exactly what you did – change the subscription and set it back.

 

I think this problem came up when I used the Wizard to create the Receive Port for me or maybe when I used the Last Binding inside the Orchestration. 

 

If I remember correctly, I think that exposing the Orchestration port didn’t have this problem.

[community-content]

Not really show the best way to accomplish this. 

 

So your message that fails originates from the Orchestration?  If so, in this case I’d probably terminate the message and had logic to resend the whole request at a later time.

[community-content]

Have you taken at look at this: http://www.winterdom.com/weblog/2006/01/31/FixMessageEncodingCustomPipelineComponentSample.aspx

Not sure if it’ll really help you are not.

[community-content]

Well, you probably need to change your input value, your map, or you output schema. 

 

But the good thing is, by default BizTalk doesn’t do any schema validation.  So you’d probably only see this error when you are testing a map.

[community-content]

I assume you are debatching inside your Receive Pipeline? If so you could set an “ID” on that batch of messages.  Then, you could use a Convoy to process all of the same messages in one file.  At this point, you can use Orchestration Instance Id, or any random ID (even the ID you set for the message, to be your unique ID. 

 

I’ve done something like this in the past and setting the ID on the message inside the pipeline was the key.

[community-content]

I don’t think this is possible.  I tried to accomplish something like this in BizTalk 2004 when there was an error I wanted a specific code to be returned.  I tried all kinds of Http / IIS settings to try to return a different error code with no luck.

[community-content]

You might be able to set your own tracking id inside a custom receive pipeline.

 

Otherwise, I think BAM might be able to help accomplish this. 

 

If you find a good solution, please let me know.

[community-content]

You could write a simple .net component to read from a config file, a database, anyplace you want.  This would then be called from an Scripting Functoid and you can pass this into the database functoid. 

 

Hope this helps.

[Author]

Posts