1 Reply Latest reply on Jul 27, 2015 5:43 PM by jdmarti1_rc

Multiple agruments on interface limitation

aaroncirillo Jan 22, 2015 1:39 PM

I am attempting to write a SOAP service that is going to consume a message from a third party which is Salesforce. I do not have control over the format of this message, since I am not generating it. Salesforce gives me a WSDL that describes the message they are going to send. I am generating code from the WSDL and then attempting to implement the interface that was defined during the generation of the code. This is the interface for the inbound message:

public interface NotificationPort {

/**

* Process a number of notifications.

public boolean notifications(java.lang.String organizationId,

java.lang.String actionId,

java.lang.String sessionId,

java.lang.String enterpriseUrl,

java.lang.String partnerUrl,

java.util.List<my.companies.data.type> notification);

}

I am not sure of the approach to take here since I am currently limited to have only 1 argument on an interface in switchyard. Every suggestion I have seen around this is to wrap your message in a single object. That makes sense if you have control over the inbound message, but I do not. Can anyone point me in the right direction on this?

1. Re: Multiple agruments on interface limitation

jdmarti1_rc Jul 27, 2015 5:43 PM (in response to aaroncirillo)

Found this and trying this approach:
Due to switchyard service limitations, interface methods can only
     * have one input type. So had to create a 'composite' type
     * See https://access.redhat.com/solutions/874003

public class CompositeInterfaceParam {
    public CompositeInterfaceParam(TrainingSet trainingSet,
     PowerStatesEnum aPowerStatesEnum) {
aTrainingSet = trainingSet;
aPowerState = aPowerStatesEnum;
    }
    /*
     * Due to switchyard service limitations, interface methods can only
     * have one input type. So had to create a 'composite' type
     * See https://access.redhat.com/solutions/874003
     *
     * TODO:
     * Will have vet this out... right now think I'll just populate with all types of
     * parameters instead of making completely generic with an array of Object...
     *
     * Code review: please look at this and see if another/better way
     */
    public TrainingSet aTrainingSet;
    public PowerStatesEnum aPowerState;
}

The interface
public interface IVMManagerService {
    /*
     * Due to switchyard service limitations, interface methods can only have
     * one input type. So had to create a 'composite' type See
     * https://access.redhat.com/solutions/874003
     *
     * Also even though setupWebserviceConnection does not need a param, the
     * interface spec forces us to have at least one
     */

    public boolean setupWebserviceConnection(boolean startup);

    public boolean powerupVM(CompositeInterfaceParam aCompositeInterfaceParam)
     throws Exception;

}
Actions