I have an N-tier structure composed of WCF nodes. I need to occasionally pass very large volumes of data from a terminal node to the top node and I would like to avoid deserializing the very large data field during the intermediate hops. I can't pass directly to the top due to our fall over strategy. Is there any way to avoid deserializing my field? Thanks for any help
Maybe you can do something with a [OnDeserializing] event?
See this.
Also, the serialization events are covered in "Programming WCF Services" (2nd Ed) by Juval Lowy in Chapter 3, pgs 107-110.
I'm not sure if you can completely short-circuit deserialization though... I've never tried.
I think Terry's on the right track. I would look at that event and by using a message contract you should be able to mark the part of the message you just want to pass through. You'll probably need to do some message manipulation (tear apart the incoming message, create a "custom" outgoing message) but you should be able to have the message continue on without being looked at.
Do a search WS-Addressing too; it may provide a pattern for doing this.
I wonder if your failover strategy would be amenable to a "snapping the link" sort of thing. You would make your initial call to the intermediate node, which would eventually forward it to the terminal node. The terminal node would respond with the information necessary for the initial node to connect to it directly.
That way, load balancing or failover could determine which terminal node should be used, but after that determination is made, a direct connection could take place. Of course, you'd want to limit the duration of that direct connection to allow the failover strategy to change its mind over time.
Related
I have written a custom pipeline component assembler to modify the response ACK HL7 message.
I have invoked Assemble(pContext) of Microsoft.Solutions.BTAHL7.Pipelines.HL72fAsm in the implemented method Assemble(pContext) of IAssemblerComponent interface
gives me result IBaseMessage
which is an HL7, then I do my manipulations on it to fix one of the fields and return that modified IBaseMessage.
All these works just fine, I tried EvenLogger to verify it.
But still the Sender application doesn't receive the modified message, it receives the auto-generated message.
Is there something I'm missing out, why do I not get the custom assembler result out from the SendPipeline of 2 way receive port
Note : BTAHL7 Configuration explorer is configured for original mode. The send pipeline on RequestResponse receive port is set to my custom pipeline
My suggestion is after all the more important points.
The first thing you're employer or customer should say is NO. That is invalid HL7 and you cannot support that.
But, if they are unable to unwilling to comply, the next thing you need to do is inform your management that their non-compliance will cost you a lot of extra time and money to accommodate. To fully support this change will likely cost more then implementing the business messages, I am totally serious. This is not a problem with BizTalk Server, you app or you.
Depending on the relationship, your management can legitimately ask them how they are going to pay for this customization. It's going to cost your side a lot more to break HL7 to comply with them than it will for them to fix it.
Next, and perhaps most important, due to the nature of it's message content, HL7 has very strict completeness requirements, which they are fundamentally breaking. The Trading Partner needs to fully document this requirement to take ownership of it because there is a huge consequence, they are breaking tracing/tracking on you end.
This means that it will be substantially more difficult to investigate and resolve messaging issues for you, not them. This might raise legal or compliance issues your side needs to be aware of.
So, provided you technical, medical and legal teams are all satisfied, the first thing I would try is a Pipeline Component that simply swaps the two values, MSH10 and MSA02. That way, they will receive both values.
Finally, here's a novel solution. Since this is their problem, and a problem for every one of their trading partners, what if you offer help them fix it. All then need to do is what I suggested, swap MSH10 and MSA02 on the received message.
I'm designing a process to get XML files from our client and load them to our database, creating an order on our side.
The snag is, and isn't there always one?, the client's XML really doesn't resemble the business objects we use to load data to our database.
So I have to design a way to get the format they specify into our custom objects.
I'm considering creating "on the fly" custom objects FROM their XML and then coming up with a "map" to translate their objects into ours. That's where my head is at right now.
Essentially I don't want to write another data-load process that supports their data, I just want to get their data into our format.
I know this is basically a design question so I'm just throwing out my idea to see if it rings true with anyone else. Or if someone has done this and has a suggestion, I'm very open to hearing it. Thanks!
From your tag, c# and xml, I would generate an event upon file reception (OS level) that triggers the small app you will have to make. Structure wise, I would go with CompanyName.Object1.
Read up on XDocument for parsing and what not. XElement and its Attributes.
Bottom line, it looks like a CRM kind of implementation and from my implementation experience, it's the longuest process: parsing of incoming data. You'll have to be thorough with your clients and have them write specific..
<Nodes name="SpecificName">
Nodes = LocalName
name = Attribute("name")
Good luck.
I'd like to create C# code that accesses a WebService that has only 1 method:
public string HandleRequest(string xml).
The request itself is sent in xml, where the xml content specifies which type of action to perform and required/optional parameters as well.
The response from the service is also returned in xml and may be different per each request type that is sent.
I'd like to design a solution that will facilitate interacting with this service, and that will allow me to:
Dynamically generate an xml from given parameters (action type, other optional args, etc). Currently the xml is loaded from a file that was already created
Parse the response in an easy way (creating a strongly typed object from it?)
What's a good solution for doing this? I find it hard to come up with one, as the request/response xml is dynamic and may change from call to call.
Some additional info:
The service is Java based and is hosted under Tomcat (Axis 1.2)
There's no wsdl document for the service (even if there was, i wouldn't be able to automatically generate some strongly typed request/response classes, as the service itself receives and outputs only XML and not some complex type).
That sounds like an XML-RPC implementation could be what you are after. From Wikipedia;
XML-RPC works by sending a HTTP request to a server implementing the
protocol. The client in that case is typically software wanting to
call a single method of a remote system. Multiple input parameters can
be passed to the remote method, one return value is returned. The
parameter types allow nesting of parameters into maps and lists, thus
larger structures can be transported. Therefore XML-RPC can be used to
transport objects or structures both as input and as output
parameters.
Wikipedia also lists some Java Implementations of this protocol.
While, I've not used this specifically, I've worked with a service designed around a bastardised version of JSON-RPC. As it didn't follow the spec truely, we couldn't utilise any pre-existing implementations.
Personally, I didn't see the benefit of using such a protocol as we still needed to have clear definitions of the operations exposed by the service along with their associated constraints such as mandatory parameters etc. In addition to that, we had to handle the serialisation/deserialisation of JSON (XML in your case) to the associated object model. This was largely due to the vendor we were interacting with and their lack of conformance to the spec. If yours is conformant, then you may find that the existing implementations provided might give you a neat way of handling this.
Note the critisims regarding bloat of XML-RPC on Wikipedia too. It might pay to look into JSON-RPC as an alternative. There are certainly a few implementations listed that you can check out.
Edit: I didn't read your question properly. Sorry. I thought you were looking at providing a service. I'd still look at the links around XML-RPC/JSON-RPC as it may give you an idea as to how to knock up a test client. As far as .NET goes, I looked at the Jayrock codebase to get an idea of how the JSON-RPC protocol was implemented and if we could have used that in our scenario. You can get a rough idea as to how they handle the requests and responses. From memory, they may even have a test harness or sample code showing how to call the service. That could give you some ideas.
I'm trying to come to grips with the search contract for Modern UI applications. In my particular case the items to search for come from a web based service so I'm hesitant to pull them all over the web and then let the user search the results for potentially a single match. My question is, how shall I go about that? Preferably, I'd just hook into the QuerySubmitted event and hit the web service from there, using the String from e.QueryText. Is that considered good practice?
If all you want is a simple server side search, then yes, hooking the QuerySubmitted event and passing the query text to your service is fine. This assumes, of course, that your service supports that kind of lookup (i.e., it has a GetProductsByText rather than just a GetAllProducts).
Things get trickier if you want to use autocomplete and provide recommendations/suggestions to the user while they are typing by handing the SuggestionsRequested event. In that case, start by looking at the Search Contract Sample for an example of how to handle that (in addition to being a good resource for understanding how tow work with the Search contract in general).
You can even have a loot at https://www.simple-talk.com/content/print.aspx?article=1716 to have a better picture..!
We have a distributed system in which a Java-based server cache communicates with a C# front end, currently through object serialization.
One 'nice to have' feature that we've been kicking around for a while is the idea that when the server representation of an object changes, i.e. we add a new attribute, we shouldn't have to release an update for the front-end as well. Right now that's obviously not a possibility - you change the structure of an object, you change its serialized form, and the deserialization doesn't work (or at best captures only what it is used to picking up and no new fields).
I was wondering if anyone had encountered a similar problem before, and what sort of solutions they went through for solving it? One bright spark in the office has suggested we send XML to the client and it should directly build the UI from what is contained within that message - no construction of an object in between - but that of course brings its own problems.
All advice welcome :)
Cheers,
Dave.
you can define a "extra fields" Map<String, Object> as one of the fields in the objects you are planning updates for
however you will still need to tell the client to use it (but it will still be captured even if they don't use it regardless) and new types for the fields can break the front end when the client can't deserialize it
I would probably take a look at google protocol buffers. That protocol supports different protocol versions on the client and server side.
Use a serialization format which is more flexible.
Do not change existing DTO's, extend them
By doing so, the server can send an extended DTO, while the client deserializes the base DTO.
Many serialization frameworks have fields which is marked as optional, which you tag all the new fields with.