In my BizTalk receive port I receive JSON from a web service. I want to read the particular JSON node value(comma separated value) in custom pipeline component and promote the property for the message if the node value has the expected value.
For example :
Json Node in message
"Dept": "support, Development,Test"
So I want read the JSON node Dept and if it has value Development then I need to promote a property for the message say devDept is true otherwise false.
I have an idea how it can be done using orchestration. But I want to do this in custom pipeline component. Can any one share the idea or help on this?
There are few approaches to do this:
You can use Newtonsoft JSON library to read JSON and then promote the property. You can add this to your project using Nuget packages. And then you would need to deploy the assembly in packages folder to GAC.
Alternatively, You can also use BizTalk JSON decoder pipeline component to convert JSON to XML and then use XmlReceive pipeline to promote properties without any use of orchestration.
Both approaches are fine, depends on other processing you are doing with JSON. Deployment wise approach 2 is better as you don't have to deploy Newtonsoft Json library to GAC
As Vikas has said, you will first want to use a JSON Decoder.
To actually promote a property depending on what is in a list of values comma separated, I would use the BRE Pipeline Framework, this allows you to execute Business Rules in Policies in a pipeline, rather than having to execute it in the Orchestration. You would just have a rule that would look at that element and if it contains Development, then create the promoted property.
Please refer to SDK samples how to implement custom pipeline component for promoting a value of XPath expression under given name:
"c:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\SDK\Samples\Pipelines\ArbitraryXPathPropertyHandler"
Using this component you can evaluate and promote to specified property name any expressions like
//*[local-name()='Dept' and contains(text(), 'Development')]
Related
We would like to handle an entire BizTalk message (preferably in the form of an XLANGMessage) through a custom method (.net) that is exposed as a BRE Fact per this article.
Is it possible to define the data being passed to a particular BRE fact as being the entire message? If so, what steps are required to do so (other than defining the method's input parameter as an XLANGMessage)?
EDIT - We simply want to get the entire BizTalk message passed into some custom code so that we can process it - specifically inside the BRE through a vocabulary. The article linked above explains how to set up our custom code to be executed, but I am unable to find out how to set the data being passed to the aforementioned code to be the entire message being processed.
Technically, yes, as XLANGMessage is a .Net class and you can pass instances as Fasts to the Policy.
However, I don't think that would be a good idea. The BRE has it's own Xml Type, TypedXmlDocument, which is used to pass Xml Documents as Facts. This is what happens behind the scene with the Call Rules Shape.
XLANGMessage really just a container, the Part data can take many forms. If it's not XmlDocument, you should probably pass the Part data as it's native underlying Type.
Finally, that MSDN article title is a bit misleading. The BRE doesn't really use Assemblies specifically in any way. What you see there is just a Class Browser. It's the Classes in the Assemblies the BRE can use.
The BizTalk Business Rules Engine Pipeline Framework allows you to call a Business Rules Policy in a pipeline component. As boatseller answered, BizTalk usually wants message to be parsed into an XML format to process and the BRE also deals with XML facts.
(Full disclosure: The BRE Pipeline Framework is written by a colleague of mine at Datacom Systems New Zealand)
OK, so this is not the most useful question since I can't remember the feature in .net that does this. Basically, that's what I'm asking; what feature is this?
A year or so ago, I was working on a project and we used configuration files that mapped directly to a class using the specific attributes on the class members. This is not the standard app.config, but assemblyname.dll.xml instead.
Perhaps it's a feature within the unity framework? Just a stab in the dark.
It is not critical I figure this out today, but it is just weighing on my brain and annoys me that i can't remember!
thanks!
It's not the standard XML config, but it is built into .NET. Basically, XML serialization allows you to project an XML document from a hydrated class instance, that will map 1:1 to the class it came from and can be used to re-hydrate a new instance of that class.
This can, in the majority of cases, be done without much effort on your part. All that's usually necessary for XML serialization to work is that the object must have a public default constructor, and that all the state information you want to serialize must be public and read-write. In a few cases, some attributes are necessary to define certain behaviors, like derived classes in arrays of their parent class, and defining non-default names for field and property element tags.
One of the major uses of this is for custom configuration files as you stated; you can load the configuration from a persistent state by simply deserializing the file into an instance of the configuration object.
Article: MSDN How To Serialize an Object
This isn't part of the .Net bcl or Unity as far as I am aware. Perhaps it's some other third party or open source component? That being said, it wouldn't be too difficult to build something like this on your own using XmlSerialization.
.net allows for multi layered configuration.
Every machine has the machine.config file. each application has the app.config file (which gets renamed to applicationname.exe.config upon building), but each dll can also have it's own config file. so, if I have the following binaries in my executable folder:
flexitris.exe
flexitrisHelpers.dll
thirdPartyContent.dll
each of them can have their own config file:
flexitris.exe.config
flexitrisHelpers.dll.config
thirdPartyContent.dll.config
and all of them will be read at runtime and accessible using the normal System.Configuration namespace.
I need to create a .NET web service that accepts xml, uses this to query a database, and then returns xml. I have been given xsd files for the request and response. Could someone point me in the right direction for where I start from or an example?
I haven't used WCF before so would prefer to use a simple asmx file to do this. I know how to get the data from the database, so it's the xml and web service bits where I'm lost.
I've tried googling this for a while but don't know where to start. Thanks.
The problem you have is that asmx and WCF are both code-first web service technologies. What this means is that you generally start with classes and the web service stack takes care of exposing your types as XML across the wire.
You are starting with a schema, which is not code. So if you want to use asmx/wcf you need to model your schema in code. You can do this by inferring a class structure from your schema using xsd.exe (or svcutil.exe for WCF).
Alternatively you can model your classes by hand based on the schema definition.
Once you have your classes then you can add declarative attributes to the code (See http://msdn.microsoft.com/en-us/library/83y7df3e.aspx for asmx, DataContract and DataMember for WCF). These attributes control:
how an incoming stream of XML is deserialized to a type when a service request is received, and
how instances of your response types get serialized to XML when passed out of your service
The problem with this approach is that getting your XML to validate against your XSD schemas will be a little bit hit and miss, as you cannot rely 100% on class inference from XSD, and additionally you may miss some fine detail if you are modelling it by hand.
Whichever way you do it you need to make sure that your request and response class instances cleanly serialize into XML which will validate against the XSD schemas you have been given.
Also look at a framework called WSCF-Blue which allows you to do contract-first web service design: http://wscfblue.codeplex.com/
Good luck, if you need any more detail about this please let me know via a comment.
From what I can understand, you need to build a webservice, which will accept XML as input, do some processing and spit out XML.
I assume you have a basic understanding of XML but dont know anything about XSD. In very simple terms, XSD is a document which is used to validate a XML file. Think of it a rule book for how XML file should be structed, you can read more about XSD from W3schools. Dont worry about the XSD to much right now. Get a few sample XML documents, which you need to accept as input and output. Build a console application to parse the sample XML file and get the results from the database. Then use the results to build the output XML by looking at the output sample XML. Once you have that completed, then you can use the .NET classes to validate your input and output XML from the XSD you have.
You can look at this answer to see how validation is done.
Once that is done, you can create your web service to return the XML as string.
Hope this help.
I'm a complete neub to working with WCF but have been put on a project that needs it. Although not given as a requirement I want this service to seemlessly work with any client regardless of the technology it is written in (e.g. Java).
Basically, the client will send me a block of XML which I will validate and process. If all is well, I am going to return an XML document with 2 fields in it (an exit code and a message).
If I use DataContracts (with 1 write only and 2 read only properties) will that do the trick or is there more to this than I am seeing.
Thanks much!
Clay
DataContracts are not "the solution"; the DC is one possible approach for message serialization. whether you want to use DC depends on what the XML must look like, or can look like, and also how you want or need to map from objects in program memory to messages (xml documents or fragments).
In particular, if you want or need xml attributes in the messages, then DataContracts is probably not the way to go.
DC can support this kind of input message:
<request>
<flavor>7</flavor>
<param>eiueuie</param>
</request>
notice all data is stored as xml elements. DataContract will not work for this kind of message:
<request flavor='7'>
<param>eiueuie</param>
</request>
...in which any of the message data is stored in xml attributes. If you want to use XML Attributes, then you probably want to use the XML Serializer. If you don't care one way or the other then DC will probably be fine.
BUT, the Xml Serializer cannot map private fields or properties into XML elements, while DC Can. So, if your object model requires that, then you cannot use XML Serializer and you should use DC.
To find out more on the tradeoff between DC and XMLS, read this.
Having said all that, the decision on whether to use DC or not is just one part of your design. You will also need to decide whether you want full SOAP Envelope support (which allows for things like message signatures and so on) or whether you want the simpler "REST" message format, which is probably better called "plain old XML" .
And then there are things like instancing, hosting and activation (use IIS or self-host?), logging/auditing, security (authentication and authorization), and so on.
So, WCF can work for you, for any type of client, but the choice to use DataContracts or not is just one piece of the puzzle.
Data contract is just definition of transferred data - it is not domain object so making decision about what will be read only doesn't make sense. Client will deserialize the response and you will have no control over its processing of the data = client can change response anyway. Response can be also changed by any processing component in WCF pipeline.
Just start with DataContract and basic SOAP service (basicHttpBinding) or basic REST service (webHttpBinding + webHttpBehavior) and you will be fine.
Building an app that is relying on a 3rd party provider who has a very verbose set of SOAP services (we're talking 50+ WSDL files). Each individual WSDL however has numerous shared type declarations. When generating client code with wsdl.exe, there used to be a /sharedtypes flag that would merge duplicate entries if a type was found several times.
When I attempt to generate my client code, I bomb on these overlapping types that the 3rd party includes in all their WSDL files.
svcutil /t:code /importxmltypes [mypath]/*.wsdl
Results in error messages alluding to the type collisions. For example, a couple samples of the error messages below:
Error: There was an error verifying some XML Schemas generated during export:
The simpleType 'http://common.soap.3rdparty.com:CurrencyNotation' has already been
declared.
Error: There was an error verifying some XML Schemas generated during export:
The complexType 'http://common.soap.3rdparty.com:NumberFormat' has already been
declared.
I do not have control over the output of the WSDLs. I do not want to have to edit the WSDLs by hand for fear of an error that breaks in a fashion at runtime that would be highly difficult to track back to our editing of the WSDL files. Not to mention that there are 50 some WSDL files that range from 200-1200 lines of XML. (Remind me again why we thought SOAP was the great salvation to us all back in the late 90s?)
Try specifying all the WSDLs in one command:
svcutil http://example.com/service1?wsdl http://example.com/service2?wsdl ...
This should automatically take care of duplicate types. Another option is to take a look at the /reference command switch:
/reference:<file path> - Add the specified assembly to the set of
assemblies used for resolving type
references. If you are exporting or
validating a service that uses 3rd-party
extensions (Behaviors, Bindings and
BindingElements) registered in config use
this option to locate extension assemblies
that are not in the GAC. (Short Form: /r)
This means that if you already have some types defined in some assembly you may include this assembly and svcutil will exclude types from it to avoid duplicates:
svcutil /reference:someassembly.dll http://example.com/service?wsdl
I was having similar problems. By defining different CLR namespaces for the different xml namespaces (using the /namespace argument of svcutil) i was able to get it working.
/namespace:http://www.opengis.net/gml,OpenGIS.GML
I have been using wsdl.exe to get round this because I work with some SOAP webservices which define the same data transfer objects at different endpoints. So I use wsdl.exe because it has the sharetypes switch. I'm not a WPF developer so I don't really care that the output does not implement IWhatever for WPF, but the classes generated are all partial so you can do some work to implement interfaces you care about in a separate file.