function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Receiving outbound messages?

Hello all.  We are about to implement SFDC and I'm currently working on the intergration and our middle tier software.  I've been to the SFDC developer training and am 100% with everything except the messaging...which seems vague at best.

We are going to create a listener or URL for all of our messages and then process each one accordingly.  I was wondering if the .NET method for this is the MSMQ?  Does the Queue work with the incoming SOAP message?  I have very limited work in the past with getting messages, so I'm trying to get a better feel for this.

Is leveraging MSMQ the way to go, or is there a better way to go to get the messages from SFDC and be able to process accordingly?

Many thanks for any insight.

Message Edited by BGrimes on 04-02-2007 08:32 AM

Message Edited by BGrimes on 04-03-2007 07:13 AM

Hi Bryan,

Although it's been a very long time since I uses MSMQ, I think what you want to do is create the web service that listens for messages and in the processing of a message you place what ever object you need on the MessageQueue (terminology?) that MSMQ.  This would seem to support biz talk if that's where you are heading.

In any case, you will need to create the web service listener.   How the payload is dispatched and to where within your systems depends on what you are trying to accomplish.

Hi Dave thanks for the reply.

I guess I'm wondering if in the .NET world what ways there are to process the formatted message from SFDC.  In my foggy memory of MSMQ, it's older and can require more work than say, a .NET web service that can be created to handle the message in real time. 

In the message from SFDC, is there a way to tie the message to the action besides the ID that I see in the XML?  Or more to the point; is it possible to tell what action created the message as to route the message to a certain destination?  We are going to have a lot of messages coming in to kick off other apps and data updates here.  I really have to be able to tell right off the bat what the message is indented to without getting some message from SFDC, parsing it out, and figuring out what changed in order to do something with it.  If I have to do this, then I think setting up different endpoints per message is better, but a total drag in development.

At this point I’m trying to see if there is a general method of handling the messages in .NET so I can explore that better.  Right now having a queue set up and pushing each message body to our middle tier is ok, but seems to be lacking power that I’m sure is available somewhere else.

Any thoughts would be very helpful.  As you can see I’m not that familiar with receiving these kinds of messages from another system, and adding the complexity of various messages that need to go to different destinations is just another layer.

Bryan Grimes

Griffin WarburtGriffin Warburt

I am in the process of doing something similar. I had hoped that we could pass commands to SFDC without receiving responses from SFDC.

I posted a question asking if this was the case and haven't heard back on it yet.

Do you mind offering some pointers? If you did end up using MSMQ did you create a Web-Service to direct the incoming messages (from SFDC) into the specific Queue for use by your application?

Was/is it possible to receive those messages directly into the calling application / DLL?


Griffin -

I ended up created endpoints on a machine outside of our firewall that's only job is for receive SFDC outbound messages.  That web service then places the messages on a public queue on a server behind the firewall which is then processes using a windows service. 

In reading this post, my problem at the time was that we are receiving about 7 different types of Account outbound messages, and I wanted a way to differentiating between them all.  What I ended up using were field updates on the record before the OM is fired out.  That way we can massage the record in order to know what to do with it downstream.

We had problems implementing MSMQ here in house because of some network configurations, so I just went with the server to server via public queues as the next best solution.

If you need to receive messages, all  you really need is a web service that SFDC can see and a way to process those messages.  One way to would be to keep everything on the same machine and just have your endpoints deserialize the message and place them into a queue on the same machine.  Then maybe a batch application can look at the queue and process the messages.  That's pretty much what I created, only with some other servers in the mix.

Good luck.  I took the developer training and looked around, but until I was faced with a 4 months project timeline and some incredibly aggressive integrations I just wasn’t seeing it.   Salesforce needs better integration workshops on approaches, known limitations, etc.  At this point with our like 12 integration points I’d still go.