Forum Replies Created
-
Posts
-
Hope this blogs helps you out:
http://dallas.sark.com/SarkBlog/mholdorf/archive/2004/10/22/442.aspx
I would create a file adapter with a filename filter for each file type using the passthrough pipeline. Likely you would have to pass it to a custom .net class to do your conversion between formats into a common, presumably xml, format. The receive msg might have to be an XmlDocument.
Alternatively you can use the FileName property to do context-based routing to the correct converter.
Nope, I don’t think that’s possible.
IIS needs to have BizTalk installed in order to put the messages in the message box.
I’m guessing you don’t like IIS and BizTalk running together. As an alternative, you could have IIS write you messages to a SQL table or Queue and then use BizTalk to read them. Not ideal, but a good work around if need be.
Make sure you are a member of the BizTalk Admin Group and SSO Admin Group. Also make sure you are deploying to the correct server.
If you are using Visual Studios to deploy, check the project properties for the deployment database.
You just need to promote a value into the message context.
Here are the steps at a high level:
- Create a property schema with a MessageContext type property
- Create a custom pipeline component to promote your batch id into this property
- In code, create a batch id and promote it
- Create a custom pipeline using your new pipeline component.
I think I have bits and pieces of all this on this site. Look at some of the BizTalk 2004 Samples. The hardest part is the custom pipeline component.
To give you an idea, this is probably 8 hours of work.
One possibility is to use the BTS.InterchangeID. This is a GUID that is assigned to the incoming message before it is debatched and all child messages will have the same InterchangeID.
You could use this as the unique id in your database, change the Id datatype in your database to GUID or varchar.
Yes, with a FF disassembler.
Could you provide any suggestions/details around how to set the ID in the pipeline? I can't access orchestration variables from the pipeline, so do I need to actually modify the message somehow in the pipeline?
Thanks,
Chris
The MessageType context property is promoted in the receive pipeline by a disassembler component.
The Pass-Thru pipeline contains no disaassembler components, so the MessageType is not promoted.
You need to use the XmlReceive pipeline in your receive location
Well it appears that the only way to solve this problem is to do the following.
Go to the cxml website and download the latest zip file. Inside there will be some example files in an example directory.
Use those examples to create the XSD.
Not offended in the least. I'm only participating in this "conversation" so that Stephen doesn't have to. Sorry if you didn't like the jab, but you can only throw around "arrogant", "bad faith", "misleading" and "failure" around so much before it comes back at you. You haven't offered anything constructive in your rant that helps anyone out, so really no reason to keep it up.
Always looking for people's business when our solutions meet their needs. As a consultant (or whatever role you are), it's your job to evaluate and consider each technology. If you don't think Microsoft's products are the right fit for technical reasons, then that's the advice you should give you customers, regardless of hurt feelings. However, in my experience, many of our products do offer the capabilities that the my customers need at a price they can handle. Match up BizTalk with virtually any other EAI/B2B/BPM product in the space, and compare the price.
Yes, I am getting the doulbe namespace error. I can see that the XML disassembler has this property you can set. Thanks a lot.
[quote user="rseroter"]
Anonymous posts are fun for everyone! It's a shame you've had a rough experience; many of BizTalk Server's 6000+ successful customers would disagree with your assessment.
To my knowledge, Microsoft has never positioned BizTalk's out of the box EDI as a "full" capability. The pitch has always been BizTalk + partner if you want anything but basic EDI functionality. EDI isn't easy to do, regardless of technology applied, so that's why you see questions on the topic. Be honest.
[/quote]Actually, EDI is easy to do with proper knowledge and capable products. Be honest.
Even when it was "jumpstart kit", Microsoft asked me to do a pilot, which I agreed to participate in, and then they withdrew because the product "wasn't ready". So even the first stab, they were pushing it as a full featured product, but discovered otherwise by themselves, fortunately before wasting our time. Instead, I implemented another product, which is still running happily at that site 6 years later. No 2002 upgrade, no 2004 upgrade, no 2006 upgrade, no radical changes whatsoever, just low impact incremental releases which were included in the maintenance contract. That's ROI.
Furthermore, I can tell you I have been called into other BizTalk projects that were spinning the bowl because the client was sold something that didn't meet their requirements. The original HIPAA product is a direct example of Microsoft selling BizTalk as fully featured, when it wasn't. I had to do a white paper to get the funding at the 11th hour for Edifecs X-Engine to save that BizTalk project.
But that was probably the fault of a "weak client", right Richard?
[quote user="rseroter"]
Similar case with Business Process Management (BPM) now. BizTalk by itself isn't full BPM (as the market defines it), but, BizTalk PLUS partner solutions can provide our customers with a full complement of functions. Does that mean that if I recommend a third party BPM product (which integrates with BizTalk), and 3 years from now we offer parallel functionality in the BizTalk products that it's a bad investment or deceitful? Not necessarily. It means we're growing the BizTalk function base to do more and more out of the box.
[/quote]
We were discussing the particular case where Microsoft promoted Covast in the 2006 release in March, and then just 3 months later, changed course. That promoted a potential bad investment, at the very least, and was deceptive to both the 3rd party and the end customer. Be honest.
[quote user="rseroter"]
BizTalk is hardly a product with no shelf life, and if you’re forced to redo projects on each release, then odds are you are a weak architect who hasn’t built solutions that accommodate change. Our customers have known for years that BizTalk releases updated versions every 18 months are so, and moving forward has one of the most exciting roadmaps of any Microsoft product. While the upgrade story from 2000/02 was admittedly rough (do to a wide-ranging framework upgrade), we've worked hard to protect the existing investments folks have made.
[/quote]
What is evidenced here is that you haven't answered any of the questions. Instead, you lash out and insinuate that I am a weak architect for not predicting where the product was going in the next releases? That's a pathetic response, Richard.
Frankly, 2002 to 2004 was also a bad upgrade. I wrote a replacement for the migrator to allow us to retain our custom functoids from 2002 , but we never did a 2004 production release, because of the issue of deployment and maintenance of all the dependent assemblies for a large scale enterprise. 2006 added nice large file handling capability, and the deployment pieces missing from 2004, but now that were just about to purchase 2006 with Covast, everything has changed, and we are now forced to re-evaluate. Part of the consideration is that we are reimplementing a platform that we just implemented 2 years ago. That is not ROI, and don't blame me for that, Richard.
I am sorry I have offended you. I have been an EDI architect for over 10 years, and I was offering my comments from that perspective. They are not unique.
Also consider that I am a customer of yours, not the other way around. Do you even want my business? How do you think your responses are impacting my product selection in the future? Is this how you treat all of your customers, by casting veiled insults at them for complaining about your poor choices?
To get out the attachment file name you can find it in the MIME properties.
Eks.// Get the n'th part and set to a new message
Out = oXMessage[n];// Set message properties
Out(FILE.ReceivedFileName) = Out(MIME.FileName);This works for me on Biztalk 2006. In Biztalk 2004 you have to use the SMTPUtils class.
Hope this hepls you out
Regards
Benny HelanderWell, if you think you can determine if you will get two messages or one then this is rather straight forward to solve inside an Orchestration with a convoy. Not sure this is possible though so this would get messy and unreliable.
The easiest is to push back and have the adapter correct the order issue. That’s probably the right approach since some day they might have more messages and overall order would be important and unpredictable.
