Restlet script to create sales order using externa...
# suitescript
m
Restlet script to create sales order using external id of customer... what's the best way? We populate the external id of customers and the sales order post json request has the external id and not the internal id. Does this require a search within the script to get the internal id or can we create the sales order without getting the internal id? Fyi we also have the same logic for tax code and items as well (using external id as part of the request), so assume solution will be the same for all... Thanks
c
the sales order will have a customer field that will require the internal ID so you'd need to do a search. If you're hitting this restlet a lot for this type of query by external ID, then a stored saved search that you load and filter on would be faster than a search.create in code every time. Or use SuiteQL.
🙏 1
m
Thanks @creece so it would be hit very frequently, 15,000 every day.. not sure if the stored saved search would be quick as we have over 100,000 customers.. the SuiteQL, would that be within the script? Trying to find the quickest and most efficient way.. thanks
f
Everyone loves rest, but if you use SOAP, you can use the external id. Oracle ❤️ Soap.
Copy code
<soapenv:Envelope xmlns:soapenv="<http://schemas.xmlsoap.org/soap/envelope/>" xmlns:platformCore="urn:<http://core_2019_2.platform.webservices.netsuite.com|core_2019_2.platform.webservices.netsuite.com>" xmlns:tranSales="urn:<http://sales_2019_2.transactions.webservices.netsuite.com|sales_2019_2.transactions.webservices.netsuite.com>">
    <soapenv:Header>
        <platformMsgs:passport xmlns:platformMsgs="urn:messages_2019_2.platform.webservices.netsuite.com">
            <platformCore:email>YOUR_EMAIL</platformCore:email>
            <platformCore:password>YOUR_PASSWORD</platformCore:password>
            <platformCore:account>YOUR_ACCOUNT_ID</platformCore:account>
            <platformCore:role internalId="YOUR_ROLE_ID"/>
        </platformMsgs:passport>
    </soapenv:Header>
    <soapenv:Body>
        <platformMsgs:add xmlns:platformMsgs="urn:messages_2019_2.platform.webservices.netsuite.com">
            <platformMsgs:record xmlns:tranSales="urn:<http://sales_2019_2.transactions.webservices.netsuite.com|sales_2019_2.transactions.webservices.netsuite.com>" xsi:type="tranSales:SalesOrder" xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>">
                <tranSales:entity>
                    <platformCore:externalId>external-id-123</platformCore:externalId>
                </tranSales:entity>
👍 1
r
Search or suiteql is your best bet still. But if you want a bit messy and not recommend solution. Then you could create a json file for external to internal id mapping. And import that in your script. Update that json file on daily basis through map reduce script. In restlet, If the json doesn't consist the external id only then do the search..
👍 1
m
@creece have you observed that stored saved searches are measurably faster than ad hoc ones? I'd also be curious to test if
N/cache
is any faster than a direct search. If you are hitting concurrency limits you can consider refactoring your restlet to be asynchronous by persisting the payloads to a staging custom record and offloading the processing to a scheduled or map/reduce script. Personally for 15k requests a day I wouldn't be sweating over a couple of lookups
👀 1
c
@michoel I just base it off it being a stored procedure that should be pre-optimized. It's kind of hard to gauge "real world" performance of it since netsuite is so wildly different account to account. It probably does not matter which you use but could test it. At 15,000 requests per day, i'd be more worried about concurrency over any performance gains. If you're creating a Sales Order, then its gonna be pretty slow to create it since its a transaction type. Add into that a few lookups and whatever other scripts have to run, then you may be sitting there a while hogging that concurrency.
If that create sales order process doesn't have to be real-time, then def offload it to a file or something and have a map/reduce come through and pick it up. Just have the RESTlet create the file which would be infinitely faster.