Forum Replies Created
-
Posts
-
There is a property on the flat file disassembler to put the data you define as the Header (in the header section of the disassembler) into the message context.
Don’t forget there is a 255 or 256 character limit and I think it’s just put the data in the header as flat file text (not XML). Not really sure though, I’ve never done it. It would mostly be used if you want the header in your output message.
Hope this helps.
You can always get the full file name and do some string manipulation either inside the Pipeline or Orchestration.
I think I do something like in this sample: http://www.biztalkgurus.com/Samples/Naming-Output-Files-Orchestration.html
Best of luck.
I don’t think it’s possible, but the System.IO.Path class can help you.
See this help topic in Visual Studio:
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1033/cpref/html/frlrfsystemiopathclasstopic.htm
Here’s the C# code which should work with slight modifications in an Expression shape (exept for the Console.WriteLine and define the variables in Orch View)
string myfilename = @\”C:\\dir\\subdir\\file1.xml\”;
string fileonly = System.IO.Path.GetFileName(myfilename);
Console.WriteLine (\”Output: File=\” + fileonly);Output: File=file1.xml
Neal Walters
http://Biztalk-Training.com – Self-Training VideosOptions
1: Debatch the data into single transactions, then call a stored proc with 3 parms on it, the stored proc updates/inserts the two tables.
2. Let Biztalk convert flat file to XML, then send entire XML block to stored proc, then use OpenXML in stored proc to update multiple tables.
I recently learned of a limitation of 8000 bytes to the parm you pass to SQL. There may be a get-around, but it looked confusing.Neal Walters
http://Biztalk-Training.comHi,
I’ve an orchestration whith a dynamic port and a FTP adapter.
The destination is construct in my orchestration
guid = System.Guid.NewGuid();
DynamicJobProcessPort(Microsoft.XLANGs.BaseTypes.Address) = \”ftp://myserver/\”+Repertoire+\”/\”+Message_Received.JobID+\”_\”+guid.ToString()+\”.jdf\”;and the value of \”Repertoire\” is calculated into the orchestration.
All is OK if the corresponding name folder exists on the FTP server!
If this folder does not exist, is it possible to catch the exception in a scope?
What is the name of the exception I’ve to intoduce in the field \”Exception object type\”?Thanks!
Raoul
I reinstalled (repaired) the Biztalk 2006 beta 2. At first it didn’t work, the results were the same.
Today, I can now edit the properties. Sorry to bother you.
Mike
Change the key settings
<xsl:key name=\”linekey\” match=\”/ns1:Order/Line\” use=\”concat(@RequestedDate,@Qty)\”/>
and
<xsl:variable name=\”group\” select=\”key(‘linekey’, concat(@RequestedDate,@Qty))\”/>
You will theoretically require one receive location for all Xml documents. The Xml Disassembler is able to derive the message type from the document.
Then one receive location for each different flat file or custom format. The Flat File disassembler requires the message type be predefined as flat files have no standard mechanism for defining message type like Xml with its root node and target namespace.One possibility is a custom disassembler that can determine the message type and call the standard Flat File disassembler
If you would create this then you could have one receive location with two disassemblers in the pipeline. The Disassembler stage in a pipeline is different from the other stages it uses FirstMatch execution mode. It calls IProbeMessage.Probe for each component until a component returns true.The other factor determining how many receive locations you have is the adapter used. How are all the suppliers sending messages? What transport protocol are they using?
I would still go for multiple receive locations, less code to write and maintain, you also get all the tracking and debugging facilities of Biztalk. It will also be easier to bring on new suppliers, just add another receive location, schema and map. With a manual disassembler every new supplier will be a new version with complete regression testing
Sorry for bothering you. It seems like it is a very known problem.
http://www.caffedharma.com/tech/archives/general/000075.html
The simplest way is to:
Create an System.Xml.XmlDocument orchestration variable, load an Xml string and assign this to a message in a message assignment shape.
[code:1:d8064e0e86]xmlDoc.LoadXml(\"<message><node/></message>\");
message = xmlDoc;[/code:1:d8064e0e86]This can get difficult if the Xml is large. In which case you could create a .Net assembly with a static method which returns System.Xml.XmlDocument
[code:1:d8064e0e86]namespace MyAssembly
class Helper{
public static System.Xml.XmlDocument CreateMessage()
{
//code create XmlDocument here
}
}[/code:1:d8064e0e86]Compile and GAC this assembly and call from a message assignment shape
[code:1:d8064e0e86]message = MyAssembly.Helper.CreateMessage();[/code:1:d8064e0e86]
Thanks Greg;
I was hoping to avoid having multiple receive locations for each provider. I was thinking of trying to manually assemble the flat files into xml, similar to how i imagine the flat file pipeline does it. Once i had it into XML i could then do the transforms dynamically.
Do think this approach will work?
Or should i just stick with multiple receive locations?
I think I found an answer…
First: pipeline one should desassemble all the schema related to IDoc to be received
Second: promote one node that would differentiate one IDoc of another
Third : Use this in the orchestrationRyan,
There are a number of ways of handling this:
1. One receive port, with one inbound map for each document type, that maps into you internal format. The port will apply the map whose input schema matches the message type of the received message. You can have one or more receive locations, but each one must have a pipeline that will identify the message type e.g using the Xml Disassembler, FlatFile Disassembler
You have one main process orchestration that binds to this receive port.
[list:0e4927cbca]Advantages: Additional suppliers just require a new map and config changes to the receive port and possibly a new receive location
Disadvantages: Issues with document validation in pipeline, requiring custom pipeline components – although this issue is addressed in BTS2006[/list:u:0e4927cbca]
2. One orchestration for each document type containing a Transform shape to map into your internal format. Plus your main process orchestration. You can use Direct ports between your transform orchestrations and the main process orchestration. You can have one or more receive ports in this scenario, each transform orchestration can bind to the same or different ports. Again you will need pipelines to identify the message type
[list:0e4927cbca]Advantages: Additional suppliers just require a new map, new transform orchestration and config changes to the receive port and possibly a new receive location. You can also use an extra transform (XSLT) for document validation.
Disadvantages: Issues with document validation in pipeline, requiring custom pipeline components – although this issue is addressed in BTS2006 or by using a XSLT validation[/list:u:0e4927cbca]
3. One main process orchestration that receives a message of type XmlDocument and uses dynamic transforms. The orchestration will identify the message type and apply the appropriate transform before it reaches the main process logic
[url]http://www.biztalkgurus.com/Samples/Dynamic-Transforms-BizTalk-2006.html[/url][list:0e4927cbca]I have not used this technique so cannot really comment, although the author is Stephen Thomas so it is definitely worth a look. Its on my todo list.
[/list:u:0e4927cbca]My current preference is option 2. I have found using XSLT to validate incoming messages far superior to the standard XML Schema validation.
You can return a list of errors rather than just the first one, you can use conditional validation based on data content. Option 3 would be open to this approach as well.
