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.
Related
I'm trying to start a little microservice application, but I'm a little bit stuck on some technicalities.
I'm trying to build an issue tracker application as an example.
It has 2 database tables, issues and comments. These will also be separate microservices, for the sake of the example.
It has to be a separate API that can be consumed by multiple types of clients e.g. mobile, web etc..
When using a monolitic approach, all the codebase is coupled together, and when making a request to let's say the REST API, I would handle for example the '/issues/19' request
to fetch the issue with the id '19' and it's corresponding comments by means of the following pseudocode.
on_request_issue(id) # handler for the route '/issues/<id>'
issue = IssuesModel.findById(id)
issue.comments = CommentsModel.findByIssueId(id)
return issue
But I'm not sure on how I should approach this with microservices. Let's say that we have microservice-issues and microservice-comments.
I could either let the client send a request to both '/issues/19' and '/comments/byissueid/19'. But that doesn't work nice in my point of view, since if we're having multiple things
we're sending alot of requests for one page.
I could also make a request to the microservice-issues and in that one also make a request to the microservice-comments, but that looks even worse to me than the above, since from what
I've read microservices should not be coupled, and this couples them pretty hard.
So then I read about API gateways, that they could/should receive a request and fan out to the other microservices but then I couldn't really figure out how to use an API gateway. Should
I write code in there for example to catch the '/issues/19' request, then fan out to both the microservice-issues and microservice-commetns, assemble the stuff and return it?
In that case, I'm feeling I'm doing the work double, won't the API gateway become a new monolith then?
Thank you for your time
API gateway sounds like what you need.
If you'll keep it simple, just to trigger internal API, it will not become your new monolith.
It will allow you do even better processing when your application grows with new microservices, or when you have to support different clients (browser, mobile apps, watch, IOT, etc)
BTW, the example you show sounds like a good exercise, in reality, for most webapps, it looks like over design. I would not break every DB call to its own microservices.
One of the motivations for breaking something to small(er) services is service autonomy, in this case the question is, when the comments service is down should you display the issue or not- if they are always coupled anyway, they probably shouldn't reside in two services, if they aren't then making two calls will let you get this decoupling
That said, you may still need an API Gateway to solve CORS issues with your client
Lastly, comments/byissueid is not a good REST interface the issueId should be a parameter /comments/?issueId=..
Am currently working on an Xamarin Form application, which requires me to interact with a Web API. There are, however times, when the call may fail, due to internet connectivity or server breaks down. In such situations, I would like to put the data that needs to be send in a queue, and try later on.
I was able to put in a queue, however, my question is, how I can run some kind of timers so that I can keep trying the API at regular interval for the ones in queue. Could someone guide me in understanding what is the best practice in such scenarios ?
Thanks
If you don't want to implement this yourself there is a Library for that.
Especially take a look at the Retry keyword.
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.
This is more a theoretical question than a practical one, but given I undestand the principles of SOA I am still a bit unsure about if this can be applied to any app.
The usual example is where a client wants to know something from a server thus we implement a service that can provide that information given a client request, it can be stateless or statefull, etc.
But what happens when we want to be notified when something happens on the server, maybe we call a service to register a search and want to be notified when a new item arrives to the server that matches or search.
Of course that can be implemented using polling and leverage that using long timeouts, but I can not see a way in the usual protocols to receive events from the server without making a call to ask.
If you can point me to an example, or tell me an architecture that could support then you have made my day.
Have you considered pub-sub (ie; WS-Eventing, WS-Notification)? These are the usual means to pushing "stuff" to interested consumers/subscribers.
You want to use a Publish-Subscribe design. If you are using WCF checkout Programming WCF by Juval Lowery. In the appdendix he shows how to build a Pub-Sub system that is actually fully Per-Call. It doesn't even rely on CallbackContracts and keeping long running Channels open and so doesn't require any reconnection logic when communication is broken...let alone the need for any polling.