function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
reptonrepton 

outbound messaging - deploying more than one listener

I have been researching this problem for days.  I previously posted a question the outbound messaging thread but it didn't register as a "new" post and I haven't heard anything on it.
 
I need to deploy multiple outbound listeners.  How can I have say, an opportunity listener and an account listener running at the same time.  Must I modify both the URL and the wsdl2java -p naming so as to get different packages.  Must I also modify the service name?
 
How can this be done.
 
thanks,
Repton
DevAngelDevAngel
Hi repton,

I have done this in dot net (it's a bit easier :smileyhappy:).  Looks like in java you may have to do some refactoring of packages and wsdd.

I'll take a closer look, but I there must be a reasonable way.  Multiple endpoints is looking like the way to go.

http://some.server.com/OM/accounts/notifications
http://some.server.com/OM/contacts/notifications
reptonrepton

Thanks for the response,

I have a 'working' solution which may prove not to be the 'best' way to go about this and if I find problems with this solution, I will post them. For my first outbound message listener on 'Account', I used the default wsdl and the default wsdl2java mappings. For my second listener based on 'Opportunity', I did the following:

I modified the Opportunity wsdl which looked like this ...

    <!-- Service Endpoint -->
    <service name="NotificationService">
        <documentation>Notification Service Implementation</documentation>
        <port binding="tns:NotificationBinding" name="Notification">
            <soap:address location="<host>/axis/services/Notification"/>
        </port>
    </service>

to this:

    <!-- Service Endpoint -->
    <service name="OpportunityService">
        <documentation>Opportunity Service Implementation</documentation>
        <port binding="tns:NotificationBinding" name="Opportunity">
            <soap:address location="<host>/axis/services/Opportunity"/>
        </port>
    </service>

Also, I used the "-p" switch in the wsdl2java (I'm using axis_1-4) to change the output package names so as to avoid collisions.

I now have two services running - 'Opportunity' and 'Notification' - and they respond so far as expected.

I did not have to modify the generated .wsdd deployment file.  I did not have to merge any code. I did not have to change the names of any generated classes. So, for now, it suits my purpose and will allow for multiple outbound messages.

thanks,

Repton
DevAngelDevAngel
That sounds like the least painful way to go.  What are the issues with this approach as you percieve them?
reptonrepton
It seems to me that there are (at least) two ways to deal with the issue of two (or more) outbound message listeners. One, the way I chose, is to use a completely different service for each listener. The other is to have only one service that would somehow route the appropriate incoming to the appropriate code.
As you mentioned, the first way is the least painful - it requires the least brain power to implement. So, to me, that means that it is the most 'java coding politically incorrect'.  I'm sure that the java gurus are rolling their eyes at this simplistic solution.
I had a chance to exercise the two listeners I created on Fri. afternoon and, without doing any real stress testing, they perform as expected. A new Acccount is created; I get the appropriate message handled by the appropriate service. A new Opportunity is created; again, I get the appropriate message.
Using Axis-1_4's WSDL2Java from the command line to generate the code is clunky and tedious - I have read that there is a plug-in of a sort for Eclipse that will give you a GUI Wizard to do this, but I haven't had time to check it out. 
An issue with using the -p switch with WSDL2Java is that it renames every generated Class package to whatever you set it to.  Without the -p switch you get the 'standard' package naming which automatically names the 'core' generated classes (like Account, Sobject) to their correct package names while naming the web service classes to 'com.sforce.soap.._2005._09...'.  This is a very minor issue and, in some ways, it is better using the -p switch because you don't have to merge the generated core classes into your existing core. Just use them like they come out - all in the same package.
Those more familiar with WSDL2Java switches (or 'options' as they are correctly called) might use the --NStoPkg <argument>=<value> option, which can be repeated as often as necessary, once for each unique namespace mapping,  to selectively rename output packages according to namespaces defined within the wsdl. A 'purist' might want to go that route.
 
This is a great board and, without it, I would not have been able to get my integration project going.  I hope these posts will help others.
 
thanks,
Repton
SumeetSumeet
Hi can u please send a sample generic OM listener in .Net actually I need it for a project where I will be getting outbound message and creating folder in sherepoint. I am ok with sharepoint deveolpment but I need the listener.
It will be a great help
Thanks
Sumeet