Excel Javascript API - Sharing - excel

(Desktop version) I'm new to using the javascript API for excel, but is it possible to create an excel add-in and share with other users without having to add the add-in to an app source etc? Can it be embedded in the excel file etc. I'd like to share scripts with other users the same way that I can share VBA if it's possible?

for security reasons as well as to make manageability of your add-ins easier, we do not store the code within the workbook, like VBA. Instead, the javascript is hosted on your website and we have a reference to your add-in saved in the workbook.
What this means, is to get a similar experience to VBA, you must either have the add-in hosted on app source (which will make it accessible via the Office Store), OR each user in an organization must have the add-in deployed or available to them (here we recommend centralized deployment as it will give the most robust experience).
This has all the current deployment options you can use for Office add-ins: https://learn.microsoft.com/en-us/office/dev/add-ins/publish/publish
thanks!

Related

Office js Excel Add-In Sharing state across workbooks

I have recently moved from developing VBA Excel Add-Ins to using the new Office JavaScript Add-ins platform. I am used to my VBA Add-In being active across the whole of Excel and the state of the variables is available no matter what workbook you are interacting with.
This does not seem to be the case with JavaScript Add-ins. I have been testing my Add-In and happened to create a new workbook and noticed that none of the Add-In state appeared to be active any longer.
Am I missing something or is this a consequence of the new Office JavaScript Add-ins architecture where it runs inside a browser within Excel?
Just to confirm I have already enabled the Shared Runtime option, that is not my question. I am able to share state between Commands, Takspane and Functions. But all within a single workbook.
I have tried one of the example Yeoman generator for Office Add-ins and it certainly seems that global variables are not shared between the Add-In in two different workbooks.
This behavior is expected. With Office (web) add-ins, each add-in runs in an embedded JavaScript runtime that is a completely separate process from Office and any other add-ins, so it cannot share data across add-ins. Some people have made sharing across add-ins work using the OfficeRuntime.storage object, but it only works in Windows. It won't work on Mac or in Office on the web. Frankly, the Office platform team considers it a bug that it can be done on Windows and that may be fixed at any time, so you should not create an add-in that depends on it even if you know your add-in will only be run on Windows.
Depending on what your scenario is, you might be able to store state in the document with either Office.document.settings or Office.document.customXmlParts. Another possibility is to store state in a database on your server side.

How do I distribute excel office add-in(w/ office.js) in privately?

Q1. Are there any method to distribute excel office add-in(w/ office.js) in privately?
(Will office.js add-in also be distributed like VSTO's .exe OR .xla/.xlam macro files with password?)
Q2. If I run office add-in server(node.js) on my on-premise server, What will have to be distributed to the end-users?
(I want to hide the core source logic unlike VBA macro.)
I am now developing an excel office add-in. But there seems to be some limitation to deploy to the end-users in my company.(We are now testing environment for pilot, and using office 365 but it is restricted by IT's policy)
When I refer to the official documentation below, the docs says that the way to deploy add-in in privately are Microsoft 365 admin center OR SharePoint catalog.(AppSource is publicly for everyone.)
refer. https://learn.microsoft.com/en-us/office/dev/add-ins/publish/publish
However, it seems that it have to use Microsoft's services or components like SharePoint or admin center. I don't want to use these items because I want to flexibly cope with various environments.
I have also read the article as below.
refer. How to distribute private office add-ins?
But the reply thread seems that the writer couldn't get the appropriate answer what I also want to know.
I want to know the other ways to distribute excel office add-in(w/ office.js) without unveiling my core source logic and what is the minimum materials I have to provide to the end-users(i.g. manifest or something).
Typically, as you have already know, you need to host the add-in's source code on the web server anywhere. The manifest file just refers to the place where the sources are stored. And the single file which should be provided to be able to side-load add-ins locally is the manifest file. Everything else is hosted under your control.
Due to the nature of the web technology you can't hide the source code from users. The add-in acts like a regular web page. The best what you could do is to obfuscate your code.

Excel add-in interaction with other Office365 applications

I'm exploring Office 365 development and I'm trying with Excel add-ins.
One thing I'd like to was to interact with other Office applications, like Outlook, OneDrive and Word - from Excel.
For example, I'd like to send an email from an Excel table and/or insert the value of a cell in a Word document.
After searching the documentation, I couldn't find if this is possible, so I'd appreciate some help.
I'm new to Office development.
Thanks in advance!
Add-ins (Office.js) run in separate instances of browsers (controlled by the Office apps). This makes it difficult to pass messages between apps. Browser storage (cookies, localStorage and IndexedDatabase) can't consistently see each other's data/events when in separate instances. Because of this, we had to pass messages through our servers just to communicate between Excel, Word, and PowerPoint on the same device. Microsoft currently does not provide an API to communicate between add-ins in different apps.

Are there more methods for the "application" object?

Am I right to conclude that I may have to wait for certain objects and methods to appear in order to launch one office App from another?
I'm trying to link a number of Excel lines (customer interactions) one to one with OneNote pages.
I cannot find Office-js methods equivalent to those used in this VBA. I looked in the Office.js documentation and see only a couple of methods.
It is perfectly possible that I'm barking up the wrong tree.
This isn't possible with using Office.js. It's important to remember that each Web Add-in runs within its own sandbox and is essentially just a web app. It simply isn't possible for a Web Add-in to determine what other applications you have and remotely execute code against them (nor would you really want this if you consider the potential security risks that would open up).
What you can do however is leverage Microsoft Graph to interact with OneNote. So rather than having Excel drive OneNote over COM, you have your Web Add-in act as middleware between the current Excel Worksheet and a user's OneNote Notebook. You Add-in uses Office.js to communicate with the Worksheet and make REST calls to Microsoft Graph to interact the Notebook.
The first thing you'll need is an Access Token for the Excel user to use with Microsoft Graph. You can obtain this using the getAccessToken() method in Office.js. The steps for setting this up can be found at Authorize to Microsoft Graph in your Office Add-in (preview).
The second thing you'll need is to call Microsoft Graph. Assuming you want to keep things simple, I would use the Microsoft Graph Client SDK for Javascript for this. You'll also want to take a look at the OneNote API overview
from Microsoft Graph's documentation.
There are also some samples in OneNote's GitHub. Although none of the samples are exactly what you're looking for, they may still provide some valuable insights into how the API works.

Does SharePoint Support VBA?

I have read very little content regarding Sharepoint (SP), and most of my reading has been sales pitch oriented overview material. I utilitze VBA with Office apps - especially Access - on a regular basis, and I am wondering if there is any translatable way to retain the custom functionality of writing my own VBA within Sharepoint, especially with MS Access.
I have read that Access databases can be run on SP, with tbales to list and forms to InfoPath, but I am assuming they are primarily talking about Access database apps that were built with wizards, which consist mainly of bound objects without explicitly-defined code.
Most of my app are primarily code driven with VBA because of my automation requirements, which I rely on to perform my tasks. Am I going to be able to accomplish the same thing within SP, and could anyone please provide any references on the subject, specifically?
You can use Access to distribute your front end to users, regardless of how much VBA it has, but an app with VBA code in it will not convert to run in the browser as a Web Database within Sharepoint 2010's Access Services. For that to work, you have to use the new, more powerful macros and limit yourself to the features supported by web objects. For an existing app, this means rebuilding every object from scratch.
Do you need to run your Access app in a web browser? If not, then you're barking up the wrong tree here.
AFAIK Sharepoint does not support VBA.
If you publish an Access database to SharePoint as a web database it cannot use VBA, however you can create a hybrid with the tables in SharePoint and the frontend in Access, that way you can have as much VBA etc as you want and still have the advantages of your data being stored in the SharePoint SQL server. You can store the frontend on SharePoint and have users download it through SharePoint .
The alternative is to keep a traditional Access database on the SharePoint share and access it via webDAV rather than the SharePoint web interface. You could map the SharePoint library as a local drive to make it easy.
Note that drive mapping is considered a legacy technology and will no longer be supported by Windows 11 due to the demise of IE11.

Resources