Forum Replies Created
-
Posts
-
Richard, I am looking at this relative to product selection from the perspective of a long time EDI professional.
A few months ago the release of BT2006 was touted in a press release along with the delivery of the Covast EDI solution for 2006. We were led to believe this was the next generation of the product. We started working with it.
Now, three months after that Microsoft comes along and says "we copied nearly all of the functionality of Covast and we are now giving it away for free"
Here are the reasons this gives me pause to consider this as a viable product to offer to clients.
1. It demonstrates bad faith towards partners. Covast clearly didn't going into this expecting to get stabbed in the back three months later.
2. It demonstrates bad faith towards customers. Here MS was confidently promoting a solution and at the same time they clearly had to have known that they were going to pull the rug out from that solution a short time later. Are there refunds being offered to people who were misled into buying the solution that is being essentially given for free? Is it recommended that they now switch from Covast to the Microsoft copy of Covast?
3. How are existing Microsoft/Covast customers going to be supported, now that Microsoft has taken over the revenue stream and potential for new clients for Covast?
4. A product that radically changes course within three months time should raise a red flag to any professional (excluding fanboys).
5. This is essentially a version 1 release. How long until version 3?
So in a very short time, Microsoft has once again demonstrated a lack of concern for partners, a lack of concern for customers, and a willingness to mislead, use and discard any party at any time. I guess there is no concern for a business reputation here? No concern for the customers who have been lead down a dead end?
Let me remind you of the last arrogant player in the EDI arena: Harbinger. The thought the customer was at their mercy in the late 90s and they found out the hard way that if you don't care about the customer's concerns, you get dumped. Here is their URL, you can check how well that worked out for them. http://www.harbinger.com/
I realize it was perceived as a gain to eat and discard Covast, but did anyone consider the loss?
What am I supposed to tell my customers?
I dont think so.
Even I am using Biztalk server 2006 and MMC3.0
I never had problem while opening any snap-IN
Its better u re-install the MMC3.0 console and restart the biztalk services…even Enterprise single signon
You can create a try/catch block in the orchestration using a scope.
In an expression shape in the scope
xmlDocVariable = incomingMessage;
Add an exception handler to the scope to catch System.Xml.XmlException
You don't *need* it, though you can certainly use it. If you prefer to build you own thing (possibly to avoid the extra licensing costs), then don't monitor the event log. Instead, create a service that listens to the MSBTS_ServiceInstanceSuspendedEvent event using WMI. There's a basic example of doing so in the BTS Documentation, and there are more complete several examples on the net you can find.
It depends on how you are loading the XmlDocument object…
LoadXml does not perform validation, and Load would require you to utilize a XmlValidatingReader and ValidationEventHandler for validation…you could consider using either method within a Pipeline Component and manage any exceptions at the disassemble stage before it hits your port.
My $.02, but I'm sure the actual Guru's may have a solution as well.
-Rich
I've been looking a bit at this, and it seems the HTTP adapter basically does this:
1- It checks the ContentType property of the message to send (or the one configured in the send port options).
2- IF the content type is a text content type (i.e. "text/<whatever>"), it will look at the message body part's Charset property and add the ";charset = " part to the content type of the HTTP request. If the type is not a text type, it leaves it alone.
Looking at the code, one thing I see that might get you out of the issue would be to explicitly ensure the message body part has a null or empty value value for the Charset property by the time it reaches the adapter. Since you might want to have an assembler in the send pipeline, your best bet would be to create a custom pipeline component and add it to the Encode stage of the send pipeline and change the value there after the assembler has already processed the message.
HTH,
i am sure this is not Adapter issue.
are using BAPI or iDocs.
check your material number from input and confirm Length min\max range from SAP person.
Nar-
Not the "official" Microsoft position or anything, but I see this as a natural progression. What did our customers tell us? More in the box please. So, we went out and bought the adapter IP from iWay and included that with BizTalk 2006. Our customers asked for a better integrated EDI story, so we wrote a homegrown EDI stack that comes free in R2. Covast still has a play and will offer premium services.
One could argue that if you're a Microsoft ISV partner, that your choice is to continue innovating or run the risk of Microsoft absorbing that once-ISV capability into the product stack. K2.net is an example of a ISV who DOES stay ahead of the curve. ISVs fill a space when there is a gap in our stack. It's logical to figure that if a particular gap is a large enough customer pain point, that we'll go ahead and fill it ourselves eventually.
You can call a WebService using just messaging in BizTalk 2006 by configuring correctly the send port by pointing it to an assembly containing the service proxy (such as a BizTalk assembly where you just added a web reference but didn't create an orchestration to use it).
As for dealing with the response, Richard Seroter just posted a couple of days ago an entry on doing just this:
This almost sounds like a Business Error returned from the Adapter. Are you calling a BAPI? If so, I think it’s a problem with your input message and not the adapter.
i tried this without Orchestration.
took that map generated and added to receveport inbound map and sendport filter property is receiveport.
when drop 2 files 2 file commingout and first one error"Details:"The root element is missing."
I did check namespace and rootnodes everything was good…no idea why it's not working
First you need to import the certificate into a local certificate store
Run MMC -> File -> Add/Remove SnapIn -> Add
Select Certificates -> Add -> Computer Account -> Next -> Local Computer ->Finish -> Close -> OK
Import the certificate into the Personal store
Copy the thumbprint and use this in the SOAP adapter config.
