Enterprise Add-in Management Strategies (2025-US-30MP-2576)

One of the biggest challenges that we run into when we start growing JMP within an organization is that people start learning to use JSL, and we start to see this proliferation of JSL code within the organization. One of the biggest challenges that starts happening as JMP is adopted at a larger scale within a company is this question of how do we manage all of the user generated code at scale? How do we control all of this stuff?

Over the years, there have been a lot of different methods proposed for doing this. Some come out of the computer science and software development field, version control systems. Some people propose, let's just use a shared drive somewhere. It turns out those both have their pros and cons.

To give you a little bit of a light at the end of the tunnel, there is actually a middle ground here that works quite well for this not quite... I don't want to dedicate all the resources to developing a full-blown software development company in-house to handle the software management piece of this. Not running the Wild Wild West that's just a shared drive on somebody's server.

But it turns out that those two extremes will have their pros and cons. When we're talking about Git or version control system, GitHub is usually the one that people know the best. Managing code bases? That's exactly what it does really well. It's good stuff.

Easily deploying updates? That's not its wheelhouse. It's not what it's designed to do. It's designed for professional software development workflow, and that's not what we're talking about here. It doesn't do that particularly well.

Controlling access and version permissions, of course, it does that quite well. Keeping version control, knowing how changes are tracked over time, all of those things are exactly what those version control systems are designed to do. It's not novice friendly because of all that. It is designed for professionals.

I've seen examples of it being used in the wild, but those are usually organizations that have dedicated individuals and resources and time to set up a dedicated software development group within the company. That may work in certain situations, or they may already have that for other reasons.

On the other extreme, the idea of using just JSL files and a shared folder, a shared directory on some server. It's got almost the mirror of the version control system problems. Managing the code base, not great. It's getting better with some of these cloud systems, but it's still not great.

Easily deploying updates? Sure. You just go and click the latest update. Maybe you send out an email or something or use some of the add-ins, Some of the code that has been proposed over time to help with this particular workflow that you can add into your add-ins. Definitely a possibility, but not trivial. Better than the version control system on this score.

Access control? Not great, if we're being honest. Novice friendly? Yes. It's not bad, but it's not superlative either. It turns out there's a middle ground for this. My colleague and I, my co-author and I, actually ended up coming at this from two different development activities. We both more or less landed on the same solution. It was interesting to see how we met up in the middle on this idea.

It turns out the idea is OneDrive, believe it or not. Everybody has it. It's an enterprise system. Well, not everybody, but a good chunk of organizations have access to OneDrive or an equivalent, let's just say. I'm going to use OneDrive for this session because that's what I've got, but there are equivalents.

The advantages of this, though, are really surprising. Managing the code base, it's in the same vein as being JSL, but you have more version control, or we have more edit control, and we have the ability to track history and roll back to earlier versions of the code. If something goes wrong, if we have a corruption in the code or something like that, we can roll back. We get those capabilities with using these enterprise systems that we're talking about here.

Easily deploy updates. This is where the rubber meets the road with this solution. We can set up more or less an automated update strategy for an entire company. Without having to lift a finger, realistically. It's nearly codeless. There are a couple of bits of code we need to put into our add-ins, but beyond that, it's all point and click. It's incredibly easy to do with these systems.

Control and edit permissions. Again, those come with the walls with this. You can give people view edit, you can give people download edit or download permissions. You can give people full access as you need it, and you can turn that on and off as needed. You can do it for groups. It's got policy options, things like that.

It does actually have a very good access permissions system, and it's novice friendly. Like I've been saying, very little extra coding is required. If you're already writing add-ins, you know everything you need to know to do this. It is super easy to implement.

What's the trick? Well, the trick comes when you realize that when JMP installs an add-in, the add-in is basically just a folder that contains a bunch of JSL with a couple of special files to tell JMP where to put it on the GUI and some metadata about the add-in. But for the most part, it's just a folder of JSL files that JMP takes and then puts into a specific location that it knows where to find.

The interesting thing, though, is that the important files for the add-in can be anywhere that JMP accesses. They don't have to be in that folder. You can put them anywhere you want. The thing that Hyde and I came to the realization was, what's stopping us from putting the important bits in a OneDrive folder and then just having a pointer from the add-in go to those important bits and open them on the OneDrive folder?

It turns out there's nothing. There's nothing stopping you from doing that. This is what you end up with when you do that. A couple of these next slide and the next slide are more for reference later on, but we'll walk through them just really quickly just so that we've got a little bit of narration on what's going on here.

In the OneDrive on the cloud, in the OneDrive folder is going to be the meat of the add-in. We're going to have the user interface, add-in code. That's how Hyde was coming at it. The way I was coming at it was from the idea of putting resources, large libraries of materials that would take up a lot of space on someone's hard drive, and they really only need to pull them when it's time to open. Otherwise, they don't want to take up the space on their hard drive. Any of this stuff can exist in the OneDrive folder, and that's where it lives.

On the JMP desktop is a tiny little script, 20 lines, maybe. Most of it is just making it user-readable. It does three things. Three specific things. One, it checks to see if it knows where those add-in files live. Does it have a location? If not, it needs to provide a dialog to say, "Hey, where am I supposed to look for the add-in?" Then open the add-in package. That's all it does. Those three things.

The other thing that exists on your user hard drive is what I'm calling a mirror of the OneDrive location. Now, this mirror, depending on how you set it up, either has just logical linkages, just has links to files, aliases, if you happen to know what those are, or it has copies of the actual files that are synced. There are pros and cons to both of those ways, and they both work equally well.

Option one, where you've got just logical linkages. Pros, very small file size. It's a footprint on the hard drive. It's just links, and it pulls the files at run time. You get the up-to-the-minute, accurate file information. Cons, it doesn't work when it's not connected to the internet. If you're on an airplane or something like that, and you don't have Wi-Fi access, your add-ins might not load at all.

The other con is that depending on the size of the add-in, there can be a little bit of a lag between clicking the link in JMP and the add-in opening up. Those are both cons. I wouldn't call that so much as a con, just to be aware that for larger add-ins, there may be a touch of a lag there.

Option two, which is what I'm going to show you how to do today, is the synced folder option. This option takes more space on the hard drive, but it allows offline access, and the loading is- It's not instantaneous, but it's definitely faster. If it needs to pull a newer version of a file, and it hasn't synced yet, then there may be a little bit of a lag. But the advantage to this is that as files are changed here, they're automatically copied into your local folder.

In both cases, you still have the read/write version control permissions in place. Someone makes a change on their local hard drive, it'll create a copy of the file. It won't let them change the original, and it will only reference the original. If someone goes in and tinkers with something and makes a mistake, the next time the add-in loads, it's going to load the original. It's not going to load their change. We have that version control, that protected workflow in place no matter what.

Now, setting up that OneDrive location, we can do it a number of different ways. The easiest way that I found is through Teams. That's actually where we're going to start the demo portion of this session today. In Teams, if you set up a team, set up a team in Teams, it automatically creates the SharePoint site you need. Then you can add a folder into that from Teams, and you can set up the syncing from there as well.

Then you have the option to go to the SharePoint site if you want to. This is what your users do. They go to the SharePoint site directly, and they set up the sync there. That's where you can give them permissions to view, edit, download, whatever. That's where you can give them permissions to the content/ you actually have access control the add-in as well. It's handy. Let's have a look at how we do that really quick.

This is Teams. I have the Teams. I'm actually in my Teams group right here. You go in and there's a button, usually, that shows, and I've got this small at the moment. There's a button that says create a new team. You create a new team, and you create the channel. Then, when you go into the channel, underneath the channel, there's an option here that says files.

You can create a new file or a new folder. That's usually what I do is I create a new folder, and I call it add-in content. From here, I can use my little dots, and I have options in here to either download or what I want to do is I want to sync to my SharePoint. I want to open my SharePoint Drive. This is my SharePoint Drive. It's the same location. I'm actually inside of that folder. This is the content for the add-in. This is the meat of my add-in that I'm going to show you.

Under these three dots here, there's an option that says sync. What that does is on my file system... It looks a little different on Windows, but on the Mac, what it does in my file system is it creates a shared libraries location and creates a copy of the folder here.

Now, as I make changes to this folder, because I've got edit permissions, as I create changes to this file, anyone else who has access to this will automatically get copies of those change is pushed to them. It'll get pushed up to the SharePoint site and then out to everybody else. This is where I start doing my editing.

Now, let's look at the file really quick. This one really isn't super important. This is just the content. But let's have a look at what one of these looks like. This is the add-in itself that I've created, and I'm going to walk you through... I'm not going to walk you through how to create the add-in itself because it's just using the add-in Wizard.

Let's look at what we have here. These are the parts that are the stuff that we don't care about too much. That's the stuff that JMP needs to know. The add-in Launcher and the add-in Preferences are the two that we care about. The add-in preferences, this has a folder or file. I'm going to put in here unselected because that got deleted when I was testing this the other day.

That's the way it should look for this by default. That's what's going to happen in this shell script is it's going to prompt me and say, "Hey, where is the add-in content for this add-in?" When it knows that, it's going to write it back to this preference script, so I don't have to be asked every time I run the add-in. It's just going to ask me once, and it's going to remember.

Let's look at I'm going to share this shell script really quick. Let's get rid of the blog. There are three, again, very short bit of code. There's not a lot here to look at. There is a dialog to ask where the JSL for this add-in really lives. Try to open the preferences. Then there's a loop here that either tries to open the code or ask me where it is. That's all we're looking at here.

I've created this add-in and actually put it in my add-ins folder. If I come up here to JMP and I say demo, it's going to say, hey... You can't see it down here, but it says, "Please select your directory for the training starter." Well, for this add-in. I forgot to change that text. All I'm going to do is go in and say, here's my share drive, and here's where my folder lives. I'm going to say, okay, open. The add-in was launched from the OneDrive location.

What I can do is I can go back to here, open this guy back up, and I've got a different text for this add-in file. I've gone in, and I've added the add-in itself. I'm going to go run that add-in again. Now it shows the new text down here at the bottom. To give you an idea about how complex this can be, there are two different add-ins I want to show you really quickly that both leverage this. I'm not going to go through all of the details on them. Let me close this out of the way. This is what I want.

The first is the one that I created called JMP on the Spot. This is actually using the concept that we're discussing today to pull the content for a web browser, viewer type thing. A repository or a library is probably a better way of describing. If we come in and pull up JMP on the Spot, all of this content in here exists on the cloud only. If I want to open it, it'll download that content in real-time.

Another option is the one that we, as SEs, use to manage our materials when we're learning a new release, which is really appropriate for JMP 19. But this is where our materials are stored. It's using this exact add-in. This GUI and everything associated with this lives on a OneDrive location.

If we were to go in and look at it, in fact, I have it right here. This is all that exists in the actual add-in on my hard drive is the preferences file that we saw already, and actually the exact file I showed you for the demo example. Everything else is real-time. I pulled down to my hard drive as it's being edited by the team.

As our materials for JMP 19, JMP 18 are uploaded, they're uploaded to the OneDrive, and they're automatically pulled to my machine. I don't have to worry about updating my add-ins, the videos and things, the really big content that we have sometimes we're getting training. Those live in the cloud, I don't download those. I don't have to. I don't take up the space on my hard drive to do that.

What did we see today? Well, we saw that OneDrive provides us the ability to manage the code base, provides the ability to easily deploy updates, control access and permissions, and is novice friendly, very little additional coding is required beyond if you're writing your own JSL, you already know everything you need to know to do this. All you need to do is remember one little trick that there's no rule that says the add-in has to live in the add-in repository.