I would like to use Rebus for integration with third-party application by adding triggers to that application's database so the triggers would insert records in format of Rebus message containing information about changes in database (operation type: insert, update, delete, table name and row id). Tell me please is there some way to do this easily or I would need to create stored procedure myself by looking into https://github.com/rebus-org/Rebus/blob/master/src/Rebus/Transports/Sql/SqlServerMessageQueue.cs Send method?
Alternatively I could just fire the exe with parameters from the trigger but it is not transactional.
Also I've seen this issue https://github.com/rebus-org/Rebus/issues/119 but I guess it's dead idea.
Maybe there is other recommended approach?
Update: I just realized body of Rebus message is serialized so it would be insane to do that in SQL (and even not possible without SQL-CLR) so maybe the only way would be to create custom transport with ReceiveMessage method accepting messages in my own format?
Thanks in advance :)
I've had excellent results integrating with "stuff happening in SQL Server" by using SQL Server Service Broker - not directly (i.e. as a Rebus transport implementation), but as a message queue that I could poll from the outside.
Whenever something interesting happened in the database, a trigger would query some tables and select the result set out for xml auto into an XML message that would be sent to a service broker queue.
I then had a Rebus endpoint with a System.Timers.Timer that would poll the broker queue and bus.SendLocal the received XML as a string - this way, everything from parsing the XML and on would be based on Rebus messages, retries, and error queues, and the customary reliability that follows :)
Related
I am new to Rebus and am trying to get up to speed with some patterns we currently use in Azure Logic Apps. The current target implementation would use Azure Service Bus with Saga storage preferably in Cosmos DB (still investigating that sample implementation). Maybe even use Rebus Mongo DB with Cosmos DB using the Mongo DB API (not sure if that is possible though).
One major use case we have is an event/timeout pattern, and after doing some reading of samples/forums/Stack Overflow this is not uncommon. The tricky part is that our Sagas would behave more as a Finite State Machine vs. a Directed Acyclic Graph. This mainly happens because dates are externally changed and therefore timeouts for events change.
The Defer() method does not return a timeout identifier, which we assume is an implementation restriction (Azure Service Bus returns a long). Since we must ignore timeouts that had been scheduled for an event which has now shifted in time, we see a way of having those timeouts "ignored" (since they cannot be cancelled) as follows:
Use a Dictionary<string, Guid> in our own SagaData-derived base class, where the key is some derivative of the timeout message type, and the Guid is the identifier given to the timeout message when it was created. I don't believe this needs to be a concurrent dictionary but that is why I am here...
On receipt of the event message, remove the corresponding timeout message type key from the above dictionary;
On receipt of the timeout message:
Ignore if it's timeout message type key is not present or the Guid does not match the dictionary key/value; else
Process. We could also remove the dictionary key at this point as well.
When event rescheduling occurs, simply add the timeout message type/Guid dictionary entry, or update the Guid with the new timeout message Guid.
Is this on the right track, or is there a more 'correct' way of handling defunct timeout (deferred) messages?
You are on the right track 🙂
I don't believe this needs to be a concurrent dictionary but that is why I am here...
Rebus lets your saga handler work on its own copy of the saga data (using optimistic concurrency), so you're free to model the saga data as if it's being only being accessed by one at a time.
I want to execute database operation in a handler and then send three commands to other handlers.
I want to make sure that all the execution of database operation together with sending commands occur in a transaction and whether all succeed or all fail.
I am using .net core and when I try to do this I get an exception that "This platform does not support distributed Transactions"
I was using RabbitMQ Transport and then SQL server transport but still getting the same problem.
I would like to know the best way to ensure that all the execution is ATOMIC under .NET Core and RabbitMQ or SQL Server transport.
Thanks
I am surprised that you get this particular exception, because Rebus does not participate in distributed transactions (at least not with any of the supported transports, and especially not with RabbitMQ).
Could you maybe update your question to include the full exception details (with stack trace and everything)? And maybe tell a little bit about how you're performing your database operations?
I have a requirement where third party software running on a desktop will write to a local database and I need to send some of that information to a remote web service. I don't have any control over the thirdparty software that is doing the insert but I can read the database.
My approach is to have a windows service check the local table every second for an insert, if there is an insert send the webservice request. I don't like checking every second but this whole process needs to happen in a short amount of time after the insert. Is there a better way to go about this? Some kind of listener? I don't think I can use triggers.
This will be .NET and SQL Server if that matters.
Try using the SQLDependency class. Implement the onChange method of the class to handle your processing. The following article describes the process of configuring your environment and has some sample code for this.
http://www.codeproject.com/Articles/144344/Query-Notification-using-SqlDependency-and-SqlCach
I have a program in which it insert a raw in a table after certain operations. I wan to call a web service in code behind to do some special tasks by the using of info that there is in the inserted row.
How I can do that?
Is it good idea to invoke this web service from a stored procedure or not? What are the other options?
More Details: Actually, I have an operation in my web application that take a long time to be completed and it is seriously time consuming operation. I don't want client wait until this process finish. That is why I decide write a web service to do this process in the background.
Therefore, I think it may be a good idea that when client request receive I insert his request in a table and call a web service to handle it. Moreover, I do not want to wait until web service return the result, so I will aware client from its result through the report. I do not know what is the best solution to handle it.
I usually keep myself far away from table triggers(it sounds like you're about to use an on insert trigger for a table).
I don't know your specific situation but you could either :
Call the webservice before or after you call the stored procedure, this way the data layer(stored proc) only handles data and nothing more. You're logical layer will handle the logic of calling an extra webservice.
Write a service that will periodicly read a table and notify the webservice of the latest modifications. More messy but it resembles more the effect you're trying to achieve.
There are probably more solutions but i'd need more information on what it exactly is you're doing. Right now it's kinda vague :)
It is never a good idea to call webservice from Stored procs or other DB objects. You can call it from your code, just after you execute the insert and commit it.
The problem it sounds like is that you cannot guarantee that the web service will be called unless you call it before committing the transaction. However, it sounds like the web service needs to be called after commit. In this case, it sounds like you should use a message queue. You could either build one in your database or you could use one off the shelf (http://aws.amazon.com/sqs/ or http://www.windowsazure.com/en-us/home/features/messaging/).
The steps would be:
Insert message into queue (after this is success you can return the call, depending on what your contract with the caller is)
Read message
Insert into table
Call web service
Delete message
The downside is that you will need to make the operations (inserting into the table and calling the web service) idempotent.
I'm trying to write a Postgres trigger such that when a configuration table is updated, a backend component is notified and can handle the change. I know that Oracle has the concept of a web/HTTP trigger, where you can execute an HTTP GET from the Oracle instance itself to a URL that can then handle the request at the application layer. I'm wondering if Postgres (v. 9.0.5) has the same feature, or comes with anything similar (and, subsequently, how to set it up/configure it)?
You could call a Python stored procedure with PL/Python from your trigger and make your http get request using Python's standard libraries.