This is a NEAR example that shows how to construct a transaction and send it to the RPC. It uses borsh to serialize the transaction before sending it.
https://github.com/near-examples/transaction-examples/blob/master/send-tokens-deconstructed.js
Is it possible to serialize transactions using serialization techniques other than borsh? if possible what else can I use?
Related
All, can anyone provide me some guidance on allowing NServiceBus to consume XML messages off a queue that were not created by NServiceBus. I am trying to integrate with a 3rd party system that drops XML messages to a queue. I have VERY little control over the XML the 3rd party produces.
I have tried wrapping their XML with the -Messages/- tag and I can get the message to hit the right handler, but many of the fields (especially in child classes) just deserialize to null. The 3rd party produces several "types" of messages but in all cases the XML is reasonably simple.
I'm trying to avoid writing an adapter that just reads XML and drops messages on the bus.
Any advise would be appreciated.
Thanks
The key lies in how you generate the message classes. If you can, you should get the XSD schemas from the third party that represent the XMLs they are sending you.
Then you can generate classes off the schemas using xsd.exe which will pretty much guarantee clean de-serialisation from XML to type.
If you can't get the schemas then you can again use xsd.exe to infer the schemas from the messages. However this method is not particularly fail-safe, and will expose you negatively to anything unexpected the message which does not conform to your inferred schema.
The serialization in NSB is abstracted so you could write your own serializer based on that format. You can then tell NSB to use your serializer instead of one of the built in ones.
I'm having trouble defining what my OperationContract should be when adding / updating an entity. I want to send an entity (or list of entities) to the ObjectContext via the WCF Service (which will instantiate a Business Manager for me to do the actual validation).
If the entity passes all of the validation rules (which could very well require querying the database to determine pass/fail for more complex business rules), it'll be saved to the database, and I'll need to be able to pass back its ID (Identity Column primary key) and the value of the concurrency token (timestamp column), but if it fails, obviously we want to have a message or messages saying what was wrong. In the case of an update, all we would need would be the new value of a concurrency token, but again we'd want the validation message(s).
To make it trickier, an entity could have multiple child/grandchild entities as well. For instance, a Trip will have Stops, which could potentially have Orders.
I'm just wondering how people handle this in the real world. The simplest examples just show the WCF service's operations like:
[OperationContract]
bool AddEntity(Entity e);
[OperationContract]
bool UpdateEntity(Entity e);
Does anyone have any great ideas for handling this? I guess I'm really just looking for practical advice here.
Should we be trying to save a collection of objects in one service call?
Should we be conveying the validation messages through a fault contract?
Any advice/input would be helpful, thanks!
Should we be trying to save a
collection of objects in one service
call?
If you mean saving whole object graph in one call then the answer is definitely yes. If you mean saving multiple independent object graphs (collection) in one call then the answer is probably yes. It is good idea to reduce number of roundtrips between client and service to minimum but in the same time doing this can introduce complications. You must decide if the whole collection must be saved as atomic operation or if you are happy with saving only part of the collection and returning errors for the rest. This will influence the rest of your architecture.
Should we be conveying the validation
messages through a fault contract?
Yes but only if you will use save operation as atomic because fault contract is exception and exception should break your current operation and return only validation errors. It should be enough to have single fault contract which will transfer all validation errors. Don't fire the exception for each single validation error because it can make your application pretty annoying and useless.
If you want to save only part of the collection which passes validations and return errors for the rest you should not use fault contracts. Instead of fault contracts you should have some container data contract used for response which will carry both ids and timestamps for saved data and ids and errors for unsaved data.
One little note to STEs: Passing back just Ids and timestamps can be probably tricky. I'm not sure if you don't have to turn off tracking when you want to set them and after that turn the tracking on again.
as the title suggests, is this possible?
At a superficial level yes, it is possible. But would you want to re-implement in SQL the entire SOAP stack to validate the message for ws-security, ws-metadatexchange, ws-addressing, ws-reliablemessaging and what else?
Is this a good job for sqlclr? Absolutely not. Why would sqlclr have to handle the transport and enveloping of a message? This should be handled close to where the message is accepted, way before it gets written into the database.
So let WCF handle the SOAP layer, that's one thing is actually good at. There is no reason why the database layer should end up with the entire SOAP package.
I have a question on the types that can be returned by a WCF service.Are there any specific complex types that can't be returned by a WCF service? To put more clearly, can we have any kind of complicated datatypes to be defined as Data Contracts and have them returned by the Service operations? Is there any limitation to any type?
Yes - anything that cannot be serialized into a message constrained by a XML schema file.
This includes:
interfaces (only concrete types)
generics
any data structure that doesn't just contain data, but also behavior (like a SqlConnection or something like that)
the Windows API primitives, like a Brush or other drawing elements
The main point is: whatever you're trying to send from client to server must be able to be serialized into an XML message, expressed in a XML schema, and deserialized back into a new object
I'm looking to use the MsmqIntegrationBinding to integrate with a legacy queue which has a serialized object as the message body. Has anyone come up with a way to obtain the "metadata" of the message body and create a service side class to use within the service?
For example, if I put in a serialized Product object from System A and my service needs to consume it, how do I provide MsmqMessage the type if I do not have the Product class on my side? I was thinking of reading off a message in a separate program, deserializing, and then emitting via the code dom. Ideas?
I wholeheartedly recommend against attempting to emit the deserialized type at runtime in the message destination. Either work with the XML at the destination to obtain the data you desire, or build data contracts that both the source and destination can adhere to.
Hmm... in WCF, you can define service methods which take (and optionally return) an untyped Message type. This seems to fit your bill quite nicely.
Other than with strongly typed messages, you'll have to do all the putting together of the message on the client and the taking apart on the server by means of reading the raw XML - but that seems to be what you're looking for, right?
Find more information and samples here:
WCF - Handling Generic Messages
How to pass a generic object through WCF
Untyped messages on WCF
Untyped messages have some restrictions, e.g. you can only read them once on the server, but you should be able to manage your scenario with this, I think.
Marc