Loading ...
Sorry, an error occurred while loading the content.
 

Re: [soaplite] SOAP::Lite problem(s) please help

Expand Messages
  • Byrne Reese
    A new release of SOAP::Lite will be coming out soon which will have this array encoding issue fixed. I also will be updating my collection of salesforce Perl
    Message 1 of 5 , Oct 12, 2004
      A new release of SOAP::Lite will be coming out soon which will have this
      array encoding issue fixed.

      I also will be updating my collection of salesforce Perl utilities in
      the next couple of weeks in time for the Dream Force conference which I
      will be presenting at. So stayed tuned to that as well.

      As far as SOAP::Lite being opaque - I completely agree. SOAP::Lite is a
      module that has grown pretty organically over the years, and there has
      not been much time/opportunity to stop and rethink how it was
      architected. That process is beginning however with the next release of
      SOAP::Lite. Slowly over the next several releases, we will introduce
      more abstracted interfaces, with a cleaner division between the
      functioning components of the package. That will enable users at the
      very least to modify certain components more easily to bring in the
      functionality they need.

      Also, document-literal and WSDL parsing is also high on the list.

      To be honest, I wouldn't mind hearing from the SOAP::Lite community at
      large what features they need mosts. So if you care to - put together a
      laundry list in priority order and let me know what changes you would
      like to see!

      Scott Weisman wrote:

      > Hello,
      >
      > I've been using SOAP::Lite for a project I'm working on that uses
      > sforce. I have encountered one bug and one problem that I don't know how
      > to work around. Can you help? Will the new code fix these problems?
      >
      > Also, just curious about this. The C# examples that sforce provides seem
      > extremely clear and straightforward. However, SOAP::Lite, in contrast to
      > most Perl modules I've used, is VERY opaque. I understand SOAP is pretty
      > complex, but is there some way to make things more clear?
      >
      > Here is the bug:
      >
      > The sforce "describeSObject" API returns an array of fields, each of
      > which is a hash describing all the properties of the field:
      >
      > $fieldlist = $r->valueof('//describeSObjectResponse/result/fields')
      >
      > $fieldlist is now an array reference.
      >
      > Each <fields> element looks like this (there are many <fields> elements
      > returned):
      >
      > <fields>
      > <byteLength>765</byteLength>
      > <createable>true</createable>
      > <custom>true</custom>
      > <digits>0</digits>
      > <filterable>true</filterable>
      > <label>Grouped Event</label>
      > <length>255</length>
      > <name>GroupedEvent__c</name>
      > <nameField>false</nameField>
      > <nillable>true</nillable>
      > <picklistValues>
      > <active>true</active>
      > <defaultValue>false</defaultValue>
      > <label xsi:null="true"/>
      > <value>Monday Night Lineup</value>
      > </picklistValues>
      > <picklistValues>
      > <active>true</active>
      > <defaultValue>false</defaultValue>
      > <label xsi:null="true"/>
      > <value>Women's Programming</value>
      > </picklistValues>
      > <picklistValues>
      > <active>true</active>
      > <defaultValue>false</defaultValue>
      > <label xsi:null="true"/>
      > <value>Shabbat</value>
      > </picklistValues>
      > <picklistValues>
      > <active>true</active>
      > <defaultValue>false</defaultValue>
      > <label xsi:null="true"/>
      > <value>Holidays</value>
      > </picklistValues>
      > <picklistValues>
      > <active>true</active>
      > <defaultValue>false</defaultValue>
      > <label xsi:null="true"/>
      > <value>Trips and Retreats</value>
      > </picklistValues>
      > <precision>0</precision>
      > <referenceTo xsi:null="true"/>
      > <restrictedPicklist>false</restrictedPicklist>
      > <scale>0</scale>
      > <soapType>xsd:string</soapType>
      > <type>picklist</type>
      > <updateable>true</updateable>
      > </fields>
      >
      > The problem is that picklistValues should be an array reference within
      > the field (eg $fieldlist->[0]{picklistValues} should be array ref), but
      > instead, ONLY THE LAST picklistValues element is returned and
      > $fieldlist->[0]{picklistValues} is instead a hash reference.
      >
      > Without a workaround, this bug is a show stopper for me.
      >
      > ===
      >
      > Here is the problem:
      >
      > The sforce "update" API call allows more than one object to be passed
      > for updating. I do the following:
      >
      > my $client = SOAP::Lite
      > ->readable(1)
      > ->deserializer(Salesforce::Deserializer->new())
      > ->on_action(sub {return '""'})
      > ->uri($uri)
      > ->proxy($$self{address});
      >
      > my $method = SOAP::Data
      > ->name('update')
      > ->prefix('sforce')
      > ->uri($uri)
      > ->attr({'xmlns:sfons' =>
      > 'urn:sobject.partner.soap.sforce.com'});
      >
      > if (scalar(@updatelist) > 1)
      > {
      > return $client->call($method => \SOAP::Data->value(@updatelist),
      > $self->get_session_header());
      > }
      > else
      > {
      > return $client->call($method => @updatelist[0],
      > $self->get_session_header());
      > }
      >
      > If @updatelist has a length of 1, it works fine, but for multiple items,
      > it wraps the data in an additional tag like this:
      >
      > <outer-tag>
      > <data-item>
      > <data-field>value</data-field>
      > </data-item>
      > <data-item>
      > <data-field>value</data-field>
      > </data-item>
      > </outer-tag>
      >
      > The problem is, I do NOT want the <outer-tag> wrapping at all.
      >
      > ===
      >
      > Thanks for any help you can provide,
      >
      > Scott
      >
      >
      > *Yahoo! Groups Sponsor*
      > ADVERTISEMENT
      > click here
      > <http://us.ard.yahoo.com/SIG=129977qg3/M=295196.4901138.6071305.3001176/D=groups/S=1705701014:HM/EXP=1097684167/A=2128215/R=0/SIG=10se96mf6/*http://companion.yahoo.com>
      >
      >
      >
      > ------------------------------------------------------------------------
      > *Yahoo! Groups Links*
      >
      > * To visit your group on the web, go to:
      > http://groups.yahoo.com/group/soaplite/
      >
      > * To unsubscribe from this group, send an email to:
      > soaplite-unsubscribe@yahoogroups.com
      > <mailto:soaplite-unsubscribe@yahoogroups.com?subject=Unsubscribe>
      >
      > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
      > Service <http://docs.yahoo.com/info/terms/>.
      >
      >
    • Alasdair Allan
      ... Just to be clear, are we talking about document literal, document literal, or MS wrapped document type, document literal here? Both would be useful! Some
      Message 2 of 5 , Oct 12, 2004
        Byrne Reese wrote:
        > Also, document-literal and WSDL parsing is also high on the list.

        Just to be clear, are we talking about document literal, document literal,
        or MS wrapped document type, document literal here? Both would be useful!

        Some way of generating WSDL would be handy, curerntly I'm writing a "fake"
        Java service using AXIS that take the same arguements, grabbing the WSDL
        and deploying it with the Perl service.

        Al.
        --
        Dr. A. Allan, School of Physics, University of Exeter
      • Byrne Reese
        I really wish WSDL generation was easy. Perl has not real reflection API, and because it is so loosely typed - how on earth is the WSDL generator supposed to
        Message 3 of 5 , Oct 12, 2004
          I really wish WSDL generation was easy. Perl has not real reflection
          API, and because it is so loosely typed - how on earth is the WSDL
          generator supposed to know if the developer intended a SCALAR to be an
          int, double or float?

          If anyone has any ideas - I would love to hear them!

          I am not saying it is impossible, just hard.

          Alasdair Allan wrote:

          >Byrne Reese wrote:
          >
          >
          >>Also, document-literal and WSDL parsing is also high on the list.
          >>
          >>
          >
          >Just to be clear, are we talking about document literal, document literal,
          >or MS wrapped document type, document literal here? Both would be useful!
          >
          >Some way of generating WSDL would be handy, curerntly I'm writing a "fake"
          >Java service using AXIS that take the same arguements, grabbing the WSDL
          >and deploying it with the Perl service.
          >
          >Al.
          >
          >
        • Alasdair Allan
          ... The only way that immediately springs to mind is to have some sort of function prototypes declared inline in the method s POD. This is messy, and obviously
          Message 4 of 5 , Oct 12, 2004
            Byrne Reese wrote:
            > Alasdair Allan wrote:
            > > Some way of generating WSDL would be handy, curerntly I'm writing a
            > > "fake" Java service using AXIS that take the same arguements, grabbing
            > > the WSDL and deploying it with the Perl service.
            >
            > I really wish WSDL generation was easy. Perl has not real reflection
            > API, and because it is so loosely typed - how on earth is the WSDL
            > generator supposed to know if the developer intended a SCALAR to be an
            > int, double or float?
            >
            > If anyone has any ideas - I would love to hear them!

            The only way that immediately springs to mind is to have some sort of
            function prototypes declared inline in the method's POD. This is messy,
            and obviously has problems, but at least lets you write the prototypes in
            the same place as the actual function, so you might actually remember to
            update it when/if you update the function. It also means that the final
            WSDL generation stage isn't really that painful.

            Al.
            --
            Dr. A. Allan, School of Physics, University of Exeter
          Your message has been successfully submitted and would be delivered to recipients shortly.