Forum Replies Created
-
Posts
-
Sorry, I don’t know a way around it assuming it’s really the system that’s causing a problem. It would make sense since I think it’s a reserved word in BizTalk.
What if you renamed it in the WSDL for import? Then edited the generated class manually inside BizTalk to change it back? I think there is an actually class name and then an Element name that you can change to have the serialized value still be System.
Just a thought.
Must be something with the way the Web Service is attaching the message. Is it not adding it as a supported attachment type (i.e. maybe using WS-Attachments)?
That’s the only think I could think of off hand.
This should be possible. I’d create a generic Xml Schema that contains all the elements you want to pass to the Error Orchestration. Then, I’d populate and construct the message in the catch shape. You’ll probably want a help .net class to do your work. Have it take in your exception object and return you error message.
Your 2nd problem, I think you have a problem with your subscription. Not sure what. I have a sample on my site that covers this – you might want to take a look at it to see if something is set wrong on your side.
I don’t think there is any way to get around this. It only looks at the first 3 letter after the “.”.
I think it talks more about it in the help guide, but I don’t think it mentions how to change the behavior.
What you really need is to run these as two separate instances on Virtual Machines.
I don’t really know a way to do what you want unless you have something in the message you can promote and use for routing.
Sorry I couldn’t help more.
Hmmm. You might want to go ahead and install the Enterprise Adapters which contain all the LOB systems (Peoplesoft, Siebel, etc). You want to do this because the Oracle adapter is pretty much just a simple ODBC adapter. You could use the "Oracle" adapter for regular ODBC. That may help you when you try and generate a schema against the adapter metadata …
You're describing a "singleton" orchestration where a single orchestration instance processes ALL the messages. You have to design this special since the default behavior of an orchestration is to operate in a multi-threaded fashion. This scenario is also called a "convoy." Searches for this will come up with a lot, and you can read this MSDN whitepaper on the topic (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bts_2004wp/html/956fd4cb-aacc-43ee-99b6-f6137a5a2914.asp).
Hmm. What rights does the Biztalk Host Instance account have? Is that also an admin? Does that user have "execute" rights on the proc?
Interesting question. I don't THINK that data gets captured as WMI events or anything like that. Now most of my customers have processes in place which force updates of any configuration data to go through the Dev-QA-Production cycle. So, there are never changes in production that haven't already been logged and tracked in upstream environments.
Have you checked this (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxmlnet/html/xmlgen.asp) out? I usually have a component that inflates a template of the schema, but, it's technically not bound to the schema, so if it changes, I'm hosed.
Bouncing the host service ("restart host") clears the cache, so you can try that. Did that orchestration use that port at one time, or never at all?
Interesting. So if you look at the schema you used for the SQL script (the one that got auto generated, that you should have chosen within the SQL Adapter send port configuration) does the "script" in the XSD look correct? That is, is it calling the procedure you expect?
The generate-id() function is used to ensure only one node is output.
In the example below, you generate a key using glaccount. <xsl:key name="glkey" match="/ns0:GLs/GL" use="glaccount)"/>
Loop thru the GL records <xsl:for-each select="GL">
Create a group of all records with the same glaccount value as the current GL. <xsl:variable name="group" select="key('glkey', glaccount))"/>
If the current GL record is the same as the first record in the group then output a result <xsl:if test="generate-id($group[1]) = generate-id()">If you wish to then group items by categorycode you will probably need another key.
Can you email your two schemas, and an example input and out xml file
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" xmlns:ns0="http://TestLooping.first" exclude-result-prefixes="msxsl" version="1.0">
<xsl:output indent="yes" omit-xml-declaration="yes" version="1.0" method="xml" />
<xsl:key name="glkey" match="/ns0:GLs/GL" use="glaccount)"/>
<xsl:template match="/">
<xsl:apply-templates select="/ns0:GLs" />
</xsl:template>
<xsl:template match="/ns0:GLS">
<ns0:GLS>
<xsl:for-each select="GL">
<xsl:variable name="group" select="key('glkey', glaccount))"/>
<xsl:if test="generate-id($group[1]) = generate-id()">
<GL>
<totalamount>
<xsl:value-of select="sum($group/amount)"/>
</totalamount>
<number>
<xsl:value-of select="number" />
</number>
</GL>
</xsl:if>
</xsl:for-each>
</ns0:GLS>
</xsl:template>
</xsl:stylesheet>Hi Greg,
what i am exactly looking for is i have an array of messages General Ledgers and it has lot of elements couple of them are glaccount and categorycode. I receive of array of general ledger in general ledgers. if i find same glaccount and categorycode then i need to sum up amount field in the message like
<GLs><GL><glaccount>10</glaccount><categorycode>PO</categorycode><amount>100</amount></GL>GL><glaccount>10</glaccount><categorycode>PO</categorycode><amount>100</amount></GL>
<GLs>
and what i need is if <glaccount> and <categorycode> are same then sum the <amount> node otherwise just leave it. Right now i am doing something like creating a key for <glaccount> and using my if as <xsl:if test=generate-id($glaccountgroup[1]=generate-id()> and it is working now can i use something like this <xsl:if test="generate-id($glaccountgroup[1])=generate-id() and generate-id($categorycode[1])=generate-id()"/>. please let me know.
Thanks
-Mani
