Published on January 11, 2024.

Over the past few weeks, I've been posting on LinkedIn about a project that I've been working on called SuiteBrowser. SuiteBrowser is exactly what its name implies: It's a Web browser designed specifically for use with NetSuite.

I've received a lot of messages and questions about SuiteBrowser, so I thought I'd write this post to introduce the project and answer some of those questions.

Why?

The question that I've been asked the most is simply, "Why?"

It's a good question, and one I've asked myself many times over the past few weeks.

I think the best way to answer it is to explain how the idea for SuiteBrowser came to be...

SuiteBrowser's Evolution

The idea for SuiteBrowser is one that has evolved over the past few years. If you've been following my work, you may have seen posts about and mentions of projects that may have appeared to have stalled or been abandoned. The SuiteQL Schema Tool is one of them. There's also SuiteConsole. And long ago, I wrote about my Document Generator application. It was a combination of those projects that lead me to the SuiteBrowser concept.

There were non-NetSuite projects that lead me to SuiteBrowser as well. For example, late in 2022, I had been working on a project that was an alternative Tulip player. That project essentially failed, but I learned a lot from it.

But it was my recent focus on developing hybrid desktop and mobile apps that ultimately sparked the idea for what would become SuiteBrowser. Developing those hybrid apps required me to get a better, deeper understanding of Web views, and how they work within the context of a native app. I've built several hybrid apps over the past 2 years - a few desktop apps, and a few mobile apps - most of which integrated with NetSuite.

And while I was working on one of those apps, I thought back to the work I had done on the SuiteQL Schema Tool. The challenge with that app was that it used the Records Catalog API, which is only accessible if you're actually logged into NetSuite. If you look back at my December 2022 blog post about the project, you can see the direction I had started to go in. I was developing a native desktop app that required the user to log into NetSuite, and then navigate to a scriptable record (i.e. a type of record that developers can run SuiteScript against). It worked, but it was awkward. You had to log into the app, which would log you out of NetSuite if you were logged in via another browser.

Session Contexts

While working on the SuiteQL Schema Tool project, I started to learn more about, and experiment with, NetSuite session contexts. My goal with session contexts was to be able to reliably, and programmatically, interact with NetSuite on behalf of the user that is logged in. I needed to do that in order for the SuiteQL Schema Tool to make calls against the Records Catalog API.

That lead me to wonder what else I could do with a session context. The answer is, a lot. Because once I have a session context, I can do things such as navigate within NetSuite (to specific pages, records, etc), run SuiteScript-based scripts, and more. But where things get really interesting is that I can begin combining some of that native NetSuite functionality with functionality that a native desktop app provides. For example, I can access local data sources, local servers, functions that aren't normally available via JavaScript, and so on.

If you look again at that December 2022 blog post, you'll see that I also mentioned something called SuiteConsole. That was me experimenting with session contexts, and specifically what I could do with one using SuiteScript.

It was at that point that I had to shelve all of these projects, and I spent most of 2023 focusing on client work.

Fast forward to December of last year, and with some time off, I started experimenting with all of this again. I realized that what I really wanted was total control of the NetSuite experience. In other words, I wanted to be able to extend and enhance NetSuite in an entirely new way, which would require having control of the browser itself. It is, admittedly, a crazy idea. And only a crazy person would even attempt to develop something like this. Well, I guess I'm crazy enough to try it.

Initial Scope

After deciding to give the project a try, I scoped it out a bit. I knew that I wanted SuiteBrowser to provide a foundation on which I could finish building those projects that I had parked long ago - including the SuiteQL Schema Tool, SuiteConsole, and the Document Generator app.

I had also been planning on developing an upgraded version of the SuiteQL Query Tool - and it seemed to me that developing a version that took full advantage of what SuiteBrowser provided made sense. So that was added to the scope as well.

But I quickly realized that a big part of the scope involved SuiteBrowser's "core." If you're going to use SuiteBrowser as an alternative to your current browser, then it had better provide a decent browser experience. For example, it needs to support multiple windows, multiple tabs, and so on. But most of all, it has to be secure.

So all of that being said, here's the project scope I've been working against.

SuiteBrowser Core
• Secure.
• Support for macOS and Windows.
• Support for user preferences.
• Support for multiple windows, and multiple tabs within each window.

SuiteConsole
• Automatically load SuiteScript 2.x modules.
• Monitor usage units.

SuiteQL Query Tool
• Replicate functionality of the current SuiteScript version.
• Improve the query editor.
• Auto-complete using the index generated by the SuiteQL Schema Tool.
• Auto-complete supported SuiteQL and Oracle commands.
• Improve the display of query results.
• Support exporting results in Excel format.

SuiteQL Schema Tool
• Seamless creation of the schema index.
• Optional background indexing.
• Add support for hidden and orphaned tables.
• Utilize a SQLite in-memory database with the FTS5 Extension.

Context Bridge
• Support for ad hoc SuiteScript requests.
• Support multiple Web API instances.
• Support configuration options (port, min/max sockets).
• Support authentication and permission restrictions.

Record Information
• Provide easy access to the current record as a JSON-encoded string.

Alternative UI Support
• Alternative dashboards.
• Support for custom page types.
• Provide configuration options at the account level.

Progress Made

As of this post, I've made a lot of progress on SuiteBrowser - but there's still a lot to do.

In terms of the browser core, I have support for multiple windows and tabs in place. This turned out to be surprisingly complicated, and the model that I ended up with is very different from what I had originally thought it would be. In any case, SuiteBrowser supports multiple windows, each with one or more tabs. Moving between windows and tabs is extremely fast, and so is closing them. And resizing a window is supported, too - with a window's tabs automatically resizing proportionally as well.

Other things that we tend to take for granted with standard browsers, such as cookies, the expected behavior of the address bar, and so on, are also supported.

The browser starts up very quickly, too. The truth is, in terms of code, there's not much to SuiteBrowser.

Of all of SuiteBrowser's features, SuiteConsole is the most complete. It relies on the NetSuite session context that I mentioned earlier, and I developed a custom Xojo class to implement it.

The SuiteQL Query Tool is also pretty far along. It uses Scintilla for the query editor, and a native Xojo control for the results table. The most surprising thing about the new SuiteQL Query Tool is its speed. I'm seeing results returned as much as 80% faster than the current SuiteScript-based version. Also, it has the potential to return as many as 500,000 rows.

The SuiteQL Schema Tool is also very far along. I'm basically re-implementing what I had developed last year inside of SuiteBrowser. There are some details to work out, including how and where to store the SQLite databases that it creates. And when it is far enough along, there's also the task of using the index in the new SuiteQL Query Tool so that it can provide a better auto-complete experience.

The Record Information function is also mostly complete. This gives developers an extremely easy and fast way to "look under the hood" of a NetSuite record, and see how it is structured, the field names, and so on. If you use the "XML trick" that I wrote about back in May of 2019, then I think you'll find the Record Information function to be especially helpful. The record information is displayed as a JSON object, and presented using Scintilla, so that the attributes can be easily expanded and collapsed.

Context Bridge

One of my goals with SuiteBrowser is that it be extensible, and by that I mean that we can expand on it without having to modify or enhance the core. I want developers to be able to "plug into it" and create NetSuite solutions that would otherwise be difficult or imposible to build.

That's where the Context Bridge function comes into play. Think of it as a Web API that's built into SuiteBrowser, which you can optionally spin up. The API's foundation is your NetSuite session. Other applications can send requests to the API to do things such as run and get the results of SuiteQL queries or saved searches, navigate to and retrieve records, or run ad hoc SuiteScript.

Of all of SuiteBrowser's functionality, it's the Context Bridge that I'm most excited about. I've only begun to explore what it's capable of. But I can tell you this: It's extremely fast, and extremely versatile. And I think it's an interesting way of extending both SuiteBrowser and NetSuite itself.

Alternative UI Support

Another feature that I've been experimenting with involves providing alternatives to NetSuite's standard UI. My goal is to to be able to provide alternative interfaces to things such as the dashboard - and potentially entirely new types of pages / screens as well.

So far, the experiments that I've performed have been successful. Basically, you tell SuiteBrowser that "when a user navigates to this page, show this instead." "This page" can be anything at all - a dashboard, a list of transactions or entities, etc. "Instead" can be anything you'd like to present to the user - a remote page, a Suitelet, etc.

Future Scope

As far as future SuiteBrowser functionality goes, my list is already long, and seems to grow daily. There's the Document Generator that I wrote about long ago. There's a Resource Manager that I've been experimenting with, which would provide NetSuite with access to local resources, including printers, datasources, locally attached devices (digital scales and signage, for example), and more. I've also started work on supporting plugins (similar to how other browsers support them). And I've been experimenting with supporting themes and dark mode.

FAQ

Over the past few weeks, I've received a lot of questions about SuiteBrowser. Here are answers to some of those questions.

When will SuiteBrowser be available?
Private beta testing will begin later in January. If all goes well, then SuiteBrowser should be available to the public in mid to late Q1.

Will SuiteBrowser be open source? What will it cost?
It will be closed source, but free of charge.

How will you monetize SuiteBrowser?
Good question. I have some ideas, but I'm also open to suggestions.

What are you using to develop SuiteBrowser?
I'm developing SuiteBrowser with Xojo.

What is the underlying Web technology that SuiteBrowser is built on?
It's currently using WebKit.

Will SuiteBrowser support plugins?
At some point, yes. It's on the product roadmap. My goal is to make it as easy as possible for developers of extensions for other browsers (such as Chrome) to port their extensions to SuiteBrowser.

How does SuiteBrowser identify itself (in terms of the HTTP User-Agent string)?
You'll see "SuiteBrowser" and the version number in the header value. For example: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML,like Gecko) SuiteBrowser/1.0

Are there any "blockers" that you're running into?
There are a few places where native NetSuite pop-up windows are acting strangely. For example, the window doesn't appear when you want to add a file to the file cabinet. There are similar issues with some of the windows that pop up when entering transactions.

I'm also working to resolve a memory leak that occurs with the Context Bridge function. The leak occurs if you attempt to stop the API by closing the Context Bridge window.

Next Steps

As I mentioned above, my hope is that SuiteBrowser is far enough along by the end of January that I can make it available for private testing, followed by a more general public testing later in Q1. It depends on how things go as I finish up the scope of SuiteBrowser version 1, and how difficult it is to resolve some of those technical issues that I'm running into.

If you're interested in SuiteBrowser, look for updates here on my blog, or follow me on LinkedIn.