Is it necessary to specify the document spec in SendPort flat file assembler property?
I have read some article saying it is NOT necssary as it will use the xml namespace to find the corresponding flat file schema to assemble the xml into flat file.
However, I have tried in our case (we are using 2006R2), but seems it is not ok, we need to specify the document spec in sendport assembler component property to make it works. Otherwise, it will say cannot find the schema from the target namespace.
Any idea?
Thanks.
No, it is not required to set the DocumentSpec for the Flat File Assembler.
FFDasm will first attempt to resolve the schema by the same process as the XmlAssembler, usually by namespace#rootnodename.
However, the same rules still apply and the most important is that the namespace#rootnodename must be unique within the BizTalk Group.
So, first, make sure only one of your FF schema is deployed.
Related
Many historical posts about BizTalk Context Accessor (CodePlex), but all links are broken. Is there a state-of-the-art context accessor functoid / component to be used today? Or, is there any other way like creating helper class or something like it?
My aim is to add file name (without path) into the destination message in a map using Custom XSLT. No existing orchestration, only picking up a file and running a map to transform message from source to destination format (that requires source file name added to it...).
I solved my problem (this time) using an orchestration where I can access the context of the incoming message easily, and after mapping, inject/update the outgoing message with the file name.
I had one additional problem to solve that helped me accept using orchestration as solution this time. Two flies in one stroke.
(Problem was - note to self - I wanted to reuse destination schema in another debatching scenario, i.e. it was a envelope schema. Funny thing, BizTalk was not able to resolve body content schema if map was run in receive port. However, running map inside an orchestration, it was able to resolve the body content schema and mapping to envelope schema as destination worked.)
An alternative to the Context Accessor functiod is to use the BRE Pipeline Framework, and read the context property and inject it into the XML Payload.
In short: I have a method name provided via a JSON configuration file. I'd like to call a method using this provided name. The method (with a matching name) will exist in the backend. What's the best way of going about this?
I am not quite sure what I should be searching for as an example.
To detail: I am working with a legacy application, hence the VB.NET. I am building a single PDF file from multiple PDF sources. Most of these are as is, I simply read the configuration and grab the relevant files and the job is done. However some require processing, I'd like the configuration file to pass in a method name to be called that will perform extra processing on the PDF, whatever that may be.
As there can be a lot of PDF files that can vary, I cannot simply use a property such as "PostProcessing: true".
Any ideas?
You could use reflection to reflect method names back and check them against the name passed from the property in the config file.
Like so
Type magicType = Type.GetType("MagicClass");
MethodInfo magicMethod = magicType.GetMethod("ItsMagic");
object magicValue = magicMethod.Invoke(magicClassObject, new object[]{100});
That would work.. but to be honest, I'd go with a case statement as you'll be hardcoding the method names anyway (because they are code), and it'll be strongly typed (less chance of typos and errors).
I have a set of data rendered using ASP.Net (VB.Net) to a web page. I now want to export that data to XML. I have created some code to generate a schema, however, I don't know what to do next. I want to have the schema be in-line with the XML data, and I would like the compiler to check to make sure that the data I'm entering for the XML content validates against the included schema. Anyone know of a way to do this? The idea is for me to be able to open the resultant file in Excel with fields of the correct type.
I've build XML documents before, and this is my first schema document I've created programmatically. However, I've never worked with inline schema's, much less used them to strongly-type the XML being added to the document.
I've read over the following, which were quite helpful, but neither of which addressed the issue I mention above:
http://www.aspfree.com/c/a/XML/Generating-XML-Schema-Dynamically-Using-VBNET-2005-Essentials/
http://blogs.msdn.com/b/kaevans/archive/2007/06/05/inline-an-xml-schema-into-your-xml-document.aspx
I have no idea what you mean by "... I would like the compiler to check to make sure that the data I'm entering for the XML content validates against the included schema."
The compiler never checks that. If you want to validate your XML Document against a schema programmatically, you should probably use http://msdn.microsoft.com/en-us/library/system.xml.schema.xmlschemavalidator.aspx.
But for inlining the schema with your document, you sort of answered your own question. The second link in your question, to http://blogs.msdn.com/b/kaevans/archive/2007/06/05/inline-an-xml-schema-into-your-xml-document.aspx, is exactly what you are trying to do.
You can think of an inline XML Schema as a document-within-a-document. Well, using Kirk's example, the outermost document is more of a container which uses the undefined namespace (no schema). His example uses a document root of "DerekDoc" that belongs to the undefined namespace. You can name yours whatever you want.
Inside that root are essentially two documents. One is the inline XML Schema. You would just add it as a child element of the root. The other is the XML document that you intended to conform to the XML Schema. You will need to use the xmlns attribute to set this element to the namespace defined by your XML Schema (the target namespace of the schema).
It might work (I haven't tried it) to set the root element to the target namespace of the schema, but it might be harder for clients to validate the document since it's a forward reference.
I have some incoming XML documents, I need to check attributes that are configurable in this coming XML and if the attribute is not there in the XML document being checked add it.
The attributes to be checked will be specified in the app.config file
OrderRequest.orderDetails.orderSummary.testCount, I need to check if the testCount attribute exists under the element OrderRequest. If No add it along with it’s value which is also specified in the app.config
INCOMING XML --> Read the attributes from the app.config which need to be checked in this XML file --> Read the incoming XML using XDocument --> If the attribute is not there in the incomg XML add it to the XML.
Any ideas how I can go on this.
I wrote a series of articles on how to create custom configuration sections, which can be found here: http://dotnetslackers.com/articles/CustomConfiguration/default.aspx
Is this a static development task? What I mean is, are you only testing the testCount attribute, or is this generic to say loop through the element type and check all of its attributes to ensure they are there?
Either way, essentially you have to find an element, get its name, access your custom configuration section and lookup the name, use the GetAttribute method to check for attribute existence, and append a new attribute to the element if not.
HTH.
In a previous question I mentioned some work with a 3rd party DLL whose interface uses a series of XML inputs that are defined using DTDs. Everything has gone smoothly so far, but I still have this nagging issue with resolving the Document Type Declaration in the generated input values.
What I can't figure out is what the deciding factor is in determining where to look for the referenced DTD file. If I have a declaration that looks like this:
<!DOCTYPE ElementName SYSTEM "ElementName.dtd">
My initial thinking was that the application's current execution path is where a parser would look for the DTD. However, when I attempt to use an XML control in ASP.Net, the error I get baffles me...
Could not find file 'c:\Program Files\Microsoft Visual
Studio
9.0\Common7\IDE\ElementName.dtd'
Why is it looking for the DTD there?
Are there any XML gurus out there who can help me out on this one. I really don't have any control over the XML that is returned from this DLL so what am I supposed to do. Is there a way to "register" a DTD with the operating system? Like the GAC?
Unfortunately the library that generated the XML used a relative url for the dtd rather than a fully qualified one. As such the XmlControl's XmlDocument is using an XmlResolver class to convert the relative path to a fully qualified one. By default it uses an XmlUrlResolver (that is a concrete XmlResolver). This will try to map the location of the dtd to a location it thinks is relative to the Xml document. Trouble is, where is the XmlDocument? Probably in memory which is not relative to anything and the XmlUrlResolver is using the process location instead which in your case is Visual Studio which is located at 'c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe'.
So what can you do? Well I suppose you have to crate you own XmlResolver that inherits from XmlUrlResolver an overrides the ResolveUri method and does something appropriate. Having done that you will have to:
Create an XmlReaderSettings class and set the XmlReolver property to the class you just created.
Create an XmlReader using XmlReader.Create() passing in your document and the XmlSettings object.
Create an XmlDocument and call Load passing in the XmlReader and finally.
Set the XmlDocument property of your XmlControl to the XmlDocument.
Frankly that is all a bit of a pain, so if it where me I would just use string.Replace to remove the DTD declaration from the document before processing it into XML.
If you are feeling really brave you can create a resolver that inherits directly from XmlResolver. Once you have done that you can override the GetEntity method and then you can get the dtd document from wherever you like. I wrote one once that got dtds from files embedded as resource files, but unfortunately, I don't have the code any more :-(
If you do not actually care about validating each and every document against its DTD, you could set the XmlResolver property to null on your XmlTextReader (or XmlDocument) to ignore the DTD altogether.