Once we design our Suitelet to display helpful information, how do we handle interactions with the Suitelet by a user? In this blog post we will learn how to handle a POST request to perform important tasks.

If you’re new to this mini-series about creating Suitelets, check out our first, second, third, and fourth blog posts to catch up to speed!

Handling User Interactions: Two Ways

When a user interacts with a Suitelet, there are two basic ways to handle the changes. If we want the Suitelet to respond dynamically while the user is viewing the Suitelet, we want to use some kind of a Client Script. If we want the Suitelet to handle the changes after the user submits the information, we want to code in what’s called the “back-end.”

These two patterns are universal across all web development. If you’ve heard the terms “front-end” and “back-end” development, these essentially refer to these two possibilities. When someone is a front-end developer, they mostly just handle designing what the user sees when they view a website. This is largely what we have been learning these past few weeks as we designed the Suitelet. Front-end developers also handle JavaScript code that runs in the browser of the user. This code can display things dynamically as the user interacts with the site. For instance, if a user clicks a certain button, a pop-up might dynamically display a message to the user. “Front-end development” includes all of this. A back-end dev, on the other hand, designs the code running on the server that isn’t seen by the user. In our Suitelet, this would include (among other things) code that handles information after a user submits the form. For example, after the server receives the information posted by the user, it can create records, send emails, or do any number of really powerful and helpful things.

Not every programmer divides neatly into one of these two camps however (though some are). If someone is mingling in both the front-end and the back-end, they are considered what’s called a “full-stack” developer. A SuiteScripter, consequently, is a full-stack dev on a small scale. NetSuite makes handling both sides quite simple, so this environment is a fantastic place to start learning these important concepts that power the global web.

Handling Posted Information

Looking back at our existing Suitelet, if we click the “Submit!” button, what will happen? A blank screen… that’s what will happen! Because the server doesn’t know where to direct to on the POST, it directs us to a blank page. This isn’t ideal, so how can we make this more user friendly?

One common thing to do is simply return to the Suitelet. To the user, this just looks like the page has refreshed after submitting the information. In this tutorial, we will learn how to pass a status (we’ll call it “confirmed”) to the URL as a parameter. Then we will “post” this URL to the server, redirect to the new URL, get the parameter from the URL, and then check if “confirmed” is in the URL as a parameter and display a popup to the user if it is.

I hope this doesn’t sound too complicated! Just follow along as we develop this in two simple steps.

Step 1: Get New URL and Redirect to It

First, to accomplish this particular automation, we will actually need two additional SuiteScript modules. Import the “N/redirect” module and the “N/url” module at the top of your script. define(['N/ui/serverWidget', 'N/search', 'N/redirect', 'N/url'], function (ui, search, redirect, url) {

This step is entirely in the POST part of our onRequest function. Here’s what we need to do:

 function onRequest(context) {
    if (context.request.method === 'GET') {
        // Our Suitelet design code is in here
    } else if (context.request.method === 'POST') {
        log.debug("Suitelet is posting.")
        var params = { page_status: 'confirmed' };

        var suiteletURL = url.resolveScript({
            scriptId: 'customscript_sr_example_suitelet',
            deploymentId: 'customdeploy_example_suitelet',
            params: params
        });
        redirect.redirect({ url: suiteletURL });
    }
}

So if context.request.method is POST, that is, information is posting to the server, then we get our URL and redirect to it. There are two methods you need to know: (1) url.resolveScript and (2) redirect.redirect. The method url.resolveScript takes three values in our case. It needs the script ID, the deployment ID, and any information we want to add to the end of our URL. We can find the scriptId and deploymentId on the script record. (But ideally we would access this with the “N/runtime” module. We will likely explore this in a future tutorial.)

In that method, the added information (params) needs to be passed as an object with a key name so we can reference it later. Here’s the structure of what the URL will be like: https://...app/site/hosting/scriptlet.nl?script=360&deploy=1&compid=TSTDRV&page_status=confirmed&whence=. So you can see the params are added to the end of the URL. Now after generating the new URL variation, we can redirect to it using redirect.redirect.

Step 2: Get Parameter from URL and Show a Message

Second, now that we have our URL and the page is refreshing to the new URL with the special parameter URL information, we have to figure out how to get that parameter and display a confirmation to the user. If you’re keeping track with what we are doing, you might recognize that we need a Client Script to show the popup. So how do we connect a Client Script to our Suitelet? We covered this a few weeks ago briefly, but NetSuite actually provides a special method that looks something like this:

form.clientScriptModulePath = './sr_example_sut_handler';

This needs to be added near where we define our form in the GET part of our script. We are adding a Client Script path to our form and then indicating what that file path is. In this case it is in the same folder as our main script (indicated by the “.“). Oh, and make sure you have a Client Script file created like this is indicating!

In our connected Client Script, we can get the parameter and display a message when the page is initiated and the parameter is ‘confirmed.’

function pageInit(context) {
    var url = new URL(document.location.href);
    var page_status = url.searchParams.get('page_status');
    log.debug('page_status', page_status);

    if (page_status == 'confirmed') {
        dialog.alert({
            title: 'Yay!',
            message: 'Your request has been submitted!'
        })
    }
}

I actually didn’t know how to get the URL parameter in a Client Script, so I just Googled it! Apparently there is a native JavaScript function just for this. There is also a NetSuite API method that does the same thing, but this only works on server-side scripts, not Client-side Scripts.

var url = new URL(document.location.href);
var page_status = url.searchParams.get('page_status');

This gets the URL and searches for a parameter with a key of “page_status.” Just what we need.

Now that we have our parameter assigned to a variable, we can check if the variable is equal to ‘confirmed.’ We then display a message! If you would like to read more about the “N/ui/dialog” module, see our in-depth blog on it here.

Conclusion

Now you know some of the important principles in using a Suitelet as a “full-stack” NetSuite developer! There is certainly more, but understanding these concepts will help you get started. Feel free to experiment and try different things. If you have any questions, let us know in the comment section below. And as always, be sure to subscribe to our email list to receive new SuiteScript tutorials and tips in your inbox!