I guess this is not a specific question, but getting ideas on how to.
We have a Flex - Spring - JMS - Hibernate webapp. Our requirement is to send automatic emails when some event occurs (new user registered, user performed an import successfully). We will have the Email addressess, content, Subject, etc in the DB. We can have the Mail Server settings hardcoded (or in the db). I would like to have this as a separate service for reusabulity. I would like to get your inputs on how to achieve this and also provide some optimal solutions on what would be the best way. Do I use JMS for this or Spring's Java Mail Sender. Which is more efficient and the latest.
Hope my question isn't too vague. Your inputs are appreciated as always :)
Thanks
Harry
Here are few low-hanging choices you have (from best to worst):
Spring Email support
The Spring Framework provides a helpful utility library for sending email that shields the user from the specifics of the underlying mailing system and is responsible for low level resource handling on behalf of the client.
This is the simplest approach (not counting coding to raw JavaMail API). If you need to just send that e-mail, you don't need nothing more. You can esaily inject JavaMailSender wherever you need it.
Email support in spring-integration
Spring Integration provides support for outbound email with the MailSendingMessageHandler. It delegates to a configured instance of Spring's JavaMailSender [...]
This solutions is built on top of 1. If you need a reusable service with enterprise integration patterns bundled (like filtering, routing, enhancing, etc.) and great flexibility. If your application does a lot of integration, this might be a smart choice but is a bit more heavyweight when it comes to maintenance.
SMTPAppender in logback
The SMTPAppender accumulates logging events [...] and sends the contents [...] in an email after a user-specified event occurs. SMTP email transmission (sending) is performed asynchronously.
This Logback appender is typically used to send an e-mail yo support/administrator when an ERROR occurs, containing error event itself and few previous events. But with a little bit of configuration you can easily use to it catch specific events in your application (triggered by logging statements) and send messages. However it will be a bit cumbersome and not flexible enough.
Related
This question is for asking general advice on what tools should I use for this task, and possibly pointing me to some related tutorials.
I have a Spring Boot web application, which during operation generates log messages into a database. There is a JavaScript management tool in the making for this REST application, and 1 function of it would be to show the log messages real-time. Meaning, when the user is on the log showing page, he should see the new log messages appearing without refresing the page.
My questions:
What should be used to provide this for the javascript client at some endpoint? I'm looking at these spring boot starters right now: websocket, redis, amqp. I have not used any of these before.
How should I "catch" the log messages as they are generated inside the application? So I could send them to the client with the chosen solution.
I'm not really looking for a periodic query type of solution, but rather a server pushing the data as it appears solution.
Any suggestions and code samples are appreciated.
Storing logs in a database is usually not a good option unless you use a database which is capable of handling a lot of write requests, such as Apache Cassandra. Streaming data from a database is not the most intuitive thing to do, however.
A modern alternative is to use a messaging system such as Apache Kafka to stream logs from producing systems to multiple subscribing systems. There are multiple ways how you can achieve that. For example, for streaming logs from your Spring Boot app you could use a special log4j appender (see here and an example here). To be able to present logs in a web browser in real-time, you will need another backend system which will receive the log records from Kafka topics and forward them to JavaScript web clients via websockets, most likely using a publisher/subscriber model.
Also, you could consider using server sent events (SSE) instead of websockets. Because you have only a unidirected message flow (logs are streamed from a backend system to a javascript client in the browser, but not the other way around), SSE can be a good option as a replacement for websockets. Websockets are more difficult to operate than SSE and usually use more resources at the backend. As always, you will need to choose between trade-offs (see here).
I have an architectural problem.
I know what represents a (fanout, direct, topic, headers) exchange, bindings, queues and almost everything about message architectures. I have the following problem and I need some pieces of advice.
I would like to implement notification logic to my application, where each user will receive in real-time notification only intended for him. ( Actually, I don't want mention what are my UI and BE languages/frameworks, because of an additional level of abstraction) The UI will make a connection to RabbitMQ with WebSocket, SockJS and STOMP. My UI will be only a consumer, the BE is the writer - that one, which will add some Messages to RabbitMQ.
It's perfectly clear to me if I have a direct Exchange with routing key, which uniquely to identify the specific user (for example: my-routing-to-empoyee-with-id-1) and N-number of Queues for each user. This is too heavy to me (I don't know actually whether is normal situation to have so much queues).
Is there any solution, where I can use only one Queue and the message to be delivered only to user for who is intended ?
I know a solution, where I can have a topic exchange and to have one writer and many subscribers, but on this way, I can filter the message only on clients level, which is not so secure. :(
Actually, I found a very interesting article, which describes me a problem that I have pretty well.
What I want is called Selective Consumers and for Enterprise Integration Patterns this is an anti-pattern and we should not use it.
For more details, all who want can read this article: https://derickbailey.com/2015/07/22/airport-baggage-claims-selective-consumers-and-rabbitmq-anti-patterns/
Evenin' good people!
I'm creating a virtual whiteboard application for my third year project at university. The system uses a Flex front-end and a Spring/BlazeDS back-end. I'd say that I'm pretty new to BlazeDS and to Flex, so apologies if anything I say doesn't make a lot of sense.
I'm attempting to implement a (reasonably) secure server push from Spring/BlazeDS to the Flex application, based on groups (whiteboards).
I've discovered that BlazeDS offers a publish/subscribe messaging architecure which includes support for sub-groups. However, I can't find a way of restricting access to particular (password-protected) groups, available only to users pre-authenticated with the system. my system is also using a custom log-in process, mediated through Flex RPC calls.
Additionally, I've considered writing a custom messaging-adapter; however getting this to #autowire with the rest of my project (and a custom authentication system) has proven difficult, and so far I've had little success.
All-in-all, I'm at a little bit of a loss for how to continue. Any help would be greatly appreciated.
If I understand your problem currectly you are trying to implement ' Authorization based subscriptions'. The user can subscribe to a group only if he is authorized to so?
If so, Flex has a concept of 'subtopics' the client subscribes on to a destination with this subtopic. This subscription can be manually managed by extending Adapters in flex. override a couple of methods to do so.
when the client requests for subscribe on this 'subtopic', handle the subscription in the adapter, maintain a list of subscriptions, also there is an overriden method in the same adapter to handle the push of the messages, you can use it to find the authorization of the user and push messages accordingly. (these methods are not invoked by you directly) thre are classes in blazeds to construct the message objects and pushe it to the client i think it is AsyncMessage use this to push.
Its been a long time since I worked on this, I hope you got some direction.
I would like to implement an internal mailbox in Spring MVC application. I tried to find something out myself and I surfed RabbitMQ, JMS, AMQP etc. but I am not sure if it is what do I need. I want to allow my users to send messages among themselves but I do not mean a chat, it should be an internal mailbox, persisted to database. I am sure if I should one of mentioned frameworks and do persistance or there is another way? Could you give me some advises or links to get started with my problem?
thanks
Why do you need JMS or anything like that? I have typically used those when I needed real-time sort of messaging on my site. For a simple mailbox, just write the data to the DB on send and have a method to check if a particular use has messages waiting. If you want to get fancy, you can AJAX-enable said method and have it check on some sort of timed loop.
Within salesforce, we're envisioning someone clicking on a quote button on an Account object record and having that pass a number of fields information to 1 of two systems. One system would be a web application. The other, a windows application. I was thinking it would be a JavaScript call to the systems, but I'm not sure. What are some of my potential options? How would you guys go about doing this?
Thanks and sorry it's so broad.
One thing to look into is Outbound Messaging in Salesforce. Outbound messages are triggered as part of a workflow rule. I think you'll find outbound messaging to be a much more robust solution than an AJAX call to a web service. For instance, if your web service cannot process an incoming request, the outbound message will queue up on the Salesforce side. Then Salesforce will attempt to resend the message at regular intervals.
Outbound messaging is a great approach and I'd choose that direction for single SObject integrations when possible. However, if you need to pass any form of related list (master-detail/lookup relationship) you'll need to tackle this another way since outbound messaging only fires on a single object at a time. You can configure multiple outbound messages to get around this but this can quickly become unmanageable. JavaScript is certainly doable but using SOAP or REST from within Apex is more sturdy and secure.
I prefer REST/HTTP since Apex has had trouble consuming complex WSDL from external systems. In fact Apex is not able to consume the Force.com API or the Metadata API for size reasons. But the built-in HTTPRequest/HTTPResponse classes from Apex using either the built-in XMLStream/DOM or System.JSON classes to parse results works really well imo.