Topic
3 replies Latest Post - ‏2013-03-14T12:19:58Z by SystemAdmin
GregWilhelm
GregWilhelm
19 Posts
ACCEPTED ANSWER

Pinned topic Which Versions Of NetSuite SuiteTalk WSDL Does Cast Iron Support?

‏2012-01-18T19:21:41Z |
We ran into an issue with the Cast Iron NetSuite connector where it is sending a malformed SOAP request to NetSuite in the Search Records task. This was in an orchestration that was built by an IBM consultant.

This orchestration appears to be targeting the 2009.2 WSDL because it is pointing at the following sandbox URL.

https://webservices.sandbox.netsuite.com/services/NetSuitePort_2009_2

From looking at the SOAP request that failed, Cast Iron is getting the XML namespaces wrong. The namespace that Cast Iron sent was ‘accounting.lists.webservices.netsuite.com’. To work against SuiteTalk 2009.2, it should be ‘accounting_2009_2.lists.webservices.netsuite.com’. I figured this out by reading the SuiteTalk 2009.2 WSDL file.

https://webservices.netsuite.com/wsdl/v2010_1_0/netsuite.wsdl

I did get the request to work in SoapUI by modifying the XML namespaces - examples are below.

CAST IRON REQUEST (fails)

<search xmlns="urn:messages.platform.webservices.netsuite.com">
<searchRecord xmlns:p0="urn:accounting.lists.webservices.netsuite.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="p0:AccountSearchAdvanced">
<criteria xmlns="urn:accounting.lists.webservices.netsuite.com">
<basic>
<internalId xmlns="urn:common.platform.webservices.netsuite.com" operator="anyOf">
<searchValue xmlns="urn:core.platform.webservices.netsuite.com" internalId="149"/>
<searchValue xmlns="urn:core.platform.webservices.netsuite.com" internalId="656"/>
<searchValue xmlns="urn:core.platform.webservices.netsuite.com" internalId="565"/>
<searchValue xmlns="urn:core.platform.webservices.netsuite.com" internalId="148"/>
<searchValue xmlns="urn:core.platform.webservices.netsuite.com" internalId="772"/>
<searchValue xmlns="urn:core.platform.webservices.netsuite.com" internalId="581"/>
<searchValue xmlns="urn:core.platform.webservices.netsuite.com" internalId="163"/>
</internalId>
<isInactive xmlns="urn:common.platform.webservices.netsuite.com">
<searchValue xmlns="urn:core.platform.webservices.netsuite.com">false</searchValue>
</isInactive>
</basic>
</criteria>
</searchRecord>
</search>

MY SOAP UI REQUEST (works)

<search xmlns="urn:messages.platform.webservices.netsuite.com">
<searchRecord xsi:type="p0:AccountSearchAdvanced" xmlns:p0="urn:accounting_2009_2.lists.webservices.netsuite.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<criteria xmlns="urn:accounting_2009_2.lists.webservices.netsuite.com">
<basic>
<internalId operator="anyOf" xmlns="urn:common_2009_2.platform.webservices.netsuite.com">
<searchValue internalId="149" xmlns="urn:core_2009_2.platform.webservices.netsuite.com"/>
<searchValue internalId="656" xmlns="urn:core_2009_2.platform.webservices.netsuite.com"/>
<searchValue internalId="565" xmlns="urn:core_2009_2.platform.webservices.netsuite.com"/>
<searchValue internalId="148" xmlns="urn:core_2009_2.platform.webservices.netsuite.com"/>
<searchValue internalId="772" xmlns="urn:core_2009_2.platform.webservices.netsuite.com"/>
<searchValue internalId="581" xmlns="urn:core_2009_2.platform.webservices.netsuite.com"/>
<searchValue internalId="163" xmlns="urn:core_2009_2.platform.webservices.netsuite.com"/>
</internalId>
<isInactive xmlns="urn:common_2009_2.platform.webservices.netsuite.com">
<searchValue xmlns="urn:core_2009_2.platform.webservices.netsuite.com">false</searchValue>
</isInactive>
</basic>
</criteria>
</searchRecord>
</search>

I have no idea where CastIron is getting the 'accounting.lists.webservices.netsuite.com' XML namespace from - it doesn't exist in any of the SuiteTalk WSDL files. I'm harboring a guess here that, under the covers, Cast Iron is using templates or is hard-coding the NetSuite XML schemas instead of generating them from the WSDL files (like you'd think).

I don't see anyway to import a NetSuite WSDL file into the NetSuite Endpoint which further confirms my theory.

Here are my questions, assuming that my assumptions are correct:

Which version(s) of NetSuite SuiteTalk is the NetSuite Endpoint designed to work?

There is a button in the NetSuite Endpoint called "Update wsdl to _2011_1", but it is not active. What does this button do, update the internal templates to version 2011.1? How do you make the button active?

Does the Endpoint Connector in 6.0.3 work with NetSuite SuiteTalk 2011.2?

Thanks.
Updated on 2013-03-14T12:19:58Z at 2013-03-14T12:19:58Z by SystemAdmin
  • GregWilhelm
    GregWilhelm
    19 Posts
    ACCEPTED ANSWER

    Re: Which Versions Of NetSuite SuiteTalk WSDL Does Cast Iron Support?

    ‏2012-01-18T19:28:22Z  in response to GregWilhelm
    The URL to the 2009.2 WSDL is the incorrect one in the above post. It should be:

    https://webservices.netsuite.com/wsdl/v2009_2_0/netsuite.wsdl
    • devtfl
      devtfl
      4 Posts
      ACCEPTED ANSWER

      Re: Which Versions Of NetSuite SuiteTalk WSDL Does Cast Iron Support?

      ‏2013-03-13T22:05:31Z  in response to GregWilhelm
      I have a similar issue with vendorbills in the current version of Studio working off of the 2012.1 wsdl. The type is incorrectly spelled as Vendorbill instead of vendorbill and of course errors with unknown type.

      So... same questions. Where is that coming from if its not in the wsdl?
  • SystemAdmin
    SystemAdmin
    1250 Posts
    ACCEPTED ANSWER

    Re: Which Versions Of NetSuite SuiteTalk WSDL Does Cast Iron Support?

    ‏2013-03-14T12:19:58Z  in response to GregWilhelm
    The WebSphere Cast Iron connectors are a convenience mechanism. They do not preclude you from using other integration mechanisms supported by the endpoint application. Most of the built-in connectors are based on web services described by WSDLs. You can always use the WSDL with standard web service operations. When I have integrated with NetSuite, I have used both the built-in connector and the standard web services activities.

    You will have to weigh your requirements against the appropriateness of the behavior of a built-in or add-on connector.

    The only connector that I almost always use exclusively is the salesforce.com connector. Even with salesforce.com, I have used the enterprise WSDL when I needed to leverage functionality in a salesforce.com release later than the default associated with the connector. For several releases, I was able to just change the WSDL reference on the endpoint to access fields specific to the later release. But, about 3 years ago, salesforce.com changed the signature of an API used by the connector and my endpoint URL substitution did not work. The next Cast Iron release handled both the original and the modified API. But, in the interim, I had a required deliverable and built the orchestration using the enterprise WSDL; after the new release, I did not modify the working orchestration to use the built-in connector.