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

    Multiple agruments on interface limitation

    Aaron Cirillo Newbie

      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
          John Martin Newbie

          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;

           

           

          }