Forum Replies Created
-
Posts
-
Well, the simplest way is to create a custom pipeline with the Xml Disassembler. Then, inside the Disassembler set the Allow Unrecognized Message = True. In fact, in 2006 I think you can change this without needing a custom pipeline.
I think that would get you past the error you’re getting – you are getting the double namespace error right?
I’d almost say that smaller Orchestration would run better and faster than a single large one. It all depends on dehydration. Plus in the long run they’d be more scalable – in theory.
In any event, breaking it up is the right thing to do.
I guess I never looked at it…. Since dynamic ports are usually called inside an orchestration, I’d probably code for it using delivery notification. I think you can use DN on dynamic ports… it’s been a while since I got to play with it. In any case, that’s the route I’d go.
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.
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.
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.
.
Depends on what type of data A,B and C are.
If they are a small set of known data items that seldom changes then you could use condition functoids
e.g. if firstfield = "A"
This would hardcode the values A, B, and C into the map.If A,B, and C are part of a large set that does change, i.e. you don't want to hardcode them into the map,
then you need to use a custom Xslt with Muenchian grouping
e.g.<?xml version="1.0" encoding="utf-16"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl" version="1.0">
<xsl:output indent="yes" omit-xml-declaration="yes" version="1.0" method="xml" />
<xsl:key name="recordkey" match="/root/record" use="firstfield"/>
<xsl:template match="/">
<xsl:apply-templates select="/root" />
</xsl:template>
<xsl:template match="/root">
<root>
<xsl:for-each select="record">
<xsl:variable name="group" select="key('recordkey', firstfield)"/>
<xsl:if test="generate-id($group[1]) = generate-id()">
<Parent>
<xsl:attribute name="Value">
<xsl:value-of select="firstfield"/>
</xsl:attribute>
<xsl:for-each select="$group">
<Child>
<xsl:attribute name="Value">
<xsl:value-of select="secondfield"/>
</xsl:attribute>
</Child>
</xsl:for-each>
</Parent>
</xsl:if>
</xsl:for-each>
</root>
</xsl:template>
</xsl:stylesheet>For the record, no, I don't work for Covast.
An EDI translator is not a Razor phone.
Let me ask you – why would you move your customers from Covast to R2 and at the same time make an argument that if you just bought Covast, it is still good for three years?
What is your customer who just payed for the implementation of a product going to say when you tell him "we're changing everything we just did"? Is he going to be happy about paying you to do all that work all over again?
If I were your customer, I'd get rid of you and your software, because you have failed. You led me into a product with no shelf life and you are charging me to redo your work all over again. And since you have already proven yourself a failure, why the heck would I use you to do it again? I'd go a different direction with someone new.
I believe it is an improvement for the customers, only in the respect that the product can finally do out of the box what it has been sold as all along. The thing to be noted is that Microsoft has been deceiving customers about the capabilities of this product for an embarrassing amount of time.* That's the real arrogance, not the way they buddied up with Covast and then cannibalized them – it's the fact that they have been deceiving people into a product with inadequate traditional EDI capability all this time. This board is a testament to that. Look at all the people asking about how to hack schemas to do traditional EDI.
* I recall in implementing HIPAA on BT2000, when I looked for 997 functionality there was an asterisk which told the customer to "hire Microsoft Consulting Services to write this piece of functionality." I mean really…
Hi JB,
I have looked into this issue. I haven't been able to solve this issue yet as it seem like a BUG in File adapter (Not sure so far). But i can explain what’s going wrong.
Biztalk does create a Temp file Named: "[Your complete file name].BTS-WIP"
When it finishes writing the temp file to the specified location, it tries to rename the file to "[Your complete file name]". But unfortunately the file is already open by the existing stream and Biztalk gets the "Sharing Violation" error. Upon getting the error it deletes the "[Your complete file name].BTS-WIP" file.
You can test this your self as well. Just remove the delete permission from the Folder where Biztalk tries to create the File. Run your process and see that the "[Your complete file name].BTS-WIP" is still there as the Biztalk process was not given permission to delete the file.
I have been trying to resolve this issue but no luck so far. But I thought to share my findings with you, so you can look into this as well.
Look through these:
File Lock or Access Denied Error Message When You Save Files Over the Network
http://support.microsoft.com/default.aspx?scid=kb;EN-US;812937Files on Network Shares Open Slowly or Read-Only or You Receive an Error Message
http://support.microsoft.com/?kbid=814112turn off multi user editing
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q292122Program Opens a File As Read-Only or Returns a Sharing Violation
http://support.microsoft.com/default.aspx?scid=kb;EN-US;328170Hopefully there will be any other solution without a need to create a custom adapter. Keep the post updated if you find any thing.
Cheers
Zia
I’ve always prompted a Windows 2003 Server to be a Certificate Authority and created my own certificates for testing. It’s been a while since I’ve done it but I’m sure there is something on the MSFT site to help you out.
Not real sure if that that will work in your case, but I think it would.
Still waiting for any replies, if people out there dont have any sample certificate they can atleast guide me about my queries….
waiting….
The mass copy functoid produces the following Xslt.
<DestinationNode>
<xsl:copy-of select="SourceNode/@*"/>
<xsl:copy-of select="SourceNode/*"/>
</DestinationNode>This should effectively be the InnerXml
Can you provide an example of the input and output Xml you are seeing?
Well, you can see that the rule is failing when calling the fact: class member Cmc.Integration.ALTA.BusinessRules.RepAssignment.GetCurrentlyAvailableRep
So, do you know what that method does? If it access the registry, then the user account running the Rules Engine (RulesEngineUpdateService) would need permission to that key.
Even simpler. Use the message type "System.Xml.XmlDocument" which allows *any* type of content (it'll show up under .NET types when you choose a message type). Naturally you can't do anything with the message (like open it up) unless you write some custom code, but if you just want to use it in an orchestration for routing, that's the easiest way.
Check this out too .. http://blogs.msdn.com/richardbpi/archive/2005/10/27/485696.aspx
Clearly you've got passion about the topic. Maybe you work for Covast, don't know. And it's only my thoughts here, not my employer.
I bought my wife a RAZR phone a year+ ago and spent $400. Now I could buy one for $79. Phone is still good, I just spent more money up front to fill a need. Someone who bought BizTalk 2006 + Covast 2 months ago, will still have a perfectly good working solution 1,2,3 years from now. Could they get the base capability for "free" in 12 months? Yes, but most of my customers have needs today, and need solutions today. I haven't stopped telling folks about Covast, but I also let them know where the BizTalk product is heading. While we'll have upgrade assistance ready to move from Covast to the R2 stack, there's no reason the combination purchased today would be less than useful.
I haven't been involved in the politics of us adding this offering, but I suspect that we believe this is a long-term win for customers. Same things as with the adapters last year. I had customers buy the Peoplesoft adapters from iWay, and shortly thereafter, we purchased the IP and "gave" it away for free. In my experience, my customers were less depressed about the $$ already spent, and more excited to actually get quality support from Microsoft for the bits and be assured of a long term integrated platform. But, I'm sure others feel differently. Can only go off my own experience. Admittedly, this is a tricky time window for someone like myself in technical sales/consulting because I need to position solutions that work right now, while also educating my customers of long term implications of an investment today.
