Forum Replies Created
-
Posts
-
Yes, you need to used Xslt, either Inline Xslt in a scripting finctoid or a custom Xslt file
<xsl:for-each select="inputrecord">
<xsl:variable name="var:v1" select="'firstname' + ./position()" />
<xsl:element name="{$var:v1}">
<xsl:value-of select="."/>
</xsl:element>
</xsl:for-each>Not sure of concatenation rules with Xpath, might have to look that one up.
The envelope/document model can only be used with an Xml message. You would still have to convert your flat file into Xml using the Flat file disassembler, so any error in the flat file would result in the whole message being discarded.
If you receive Xml to start with, then the Xml Disassembler only requires that the Xml be well formed. If it is not then the whole message is discarded
Otherwise it will break down the message into individual documents. The Xml Disassembler does not validate a document against it schema. It just uses the namespace and root node to identify the schema. If you wish to validate against the schema you need to use the Xml Validator pipeline component in the next stage of the pipeline. WIth Recoverable Interchange processing neither error (cannot find schema or fails schema validation) will prevent subsequent valid documents from processingThings are much easier using Xml – probably one of the reasons for it popularity
its not actually a parallel process. it is sequential in nature. because i have to do something and then wait for the response before i continue…
am sorry if i am not understanding you properly what is "parallel convoy"?
Hi Greg,
Thanks for the reply. Not very good news for me. By using Envelope Schemas approach, could anything improve or it would be the same?
Thanks
AH
Sounds like you'll need to create your own custom disassembler component that wraps the Flat File Disassembler and implements IProbeMessage to check the message type so that you can pass the right set of schemas to the underlying FFDasmComp. Here are a few examples of wrapping the flat file disassembler.
You might also want to check out this thread for some other ideas and options.
The problem is the flat file disassembler is unable to recover from an error and so will stop.
If a record is missing from a document it cannot skip over the remaining records from that specific document and find the start of the next document. There would be too many possilibilites, given the variant nature of flat file implementations to be able to determine what recovery action should be taken.
EDI -> Flat File -> SQL . In this case I have to have 2 maps.
only 1 map in this solution also no?
But if you have the FlatFile adapter you won't be able to verify the syntax rules of the EDI file…
Depends on the method you use to call the asp.net page.
If you use the POST method (e.g. form post) then you can use the standard Http Adapter, with a map and flat file assembler to construct the form message.
If you use the GET method, then you will need to write a custom request/response Http adapter.
Or you can write a .Net class to call the asp.net page and return the result. You can call the .NET class from the orchestration. If you use a static method on this class, you do not have to instantiate the class or worry about making it serializable.The custom adapter is more complicated, but you have advantages like, using a pipeline for message manipulaton and the in-built retry capabilities.
