I am looking to extend an existing JavaScript/CoffeeScript application using the realtime API. What I want to do is synchronize a map used by the Model of my application, part of an MVC framework spinejs. This would require that all the operations of the API will be done on the Model of my application (which is pure client-side), and have no direct interaction with the View.
All the open-source examples of realtime-api I have found had the JS code within the HTML being displayed, or much of the operations for authorization/loading etc (quickstart,realtime-cube,realtime-playground).
Is it possible to use realtime-api, without having direct
interaction with the displayed content?
Furthermore, if any examples are available it would be greatly appreciated.
Once the auth is done, all the operations can be performed, without any user operation being necessary (i.e. they don't have to be triggered by a user event).
I can show you our RT code here, although it's non-trivial, the listeners are listening to our own model, which cause RT functions to be invoked.
In terms of the auth, it works fine, except if you want to support multiple accounts. For single accounts you can use the immediate mode to enable signing in without causing a popup.
If there are multiple accounts logged in, you will need a user event to start the auth without having a popup, immediate mode messes up multiple account handling. Note there is a bug in the multiple account selection screen anyway, which causes a poor user experience.
Related
I am trying to integrate our third party application with NetSuite. I want to be able to import sales invoice details generated from our third party system (which uses REST API) into the NetSuite invoice form.
The frequency of import is not too crucial- an immediate import will be ideal, but sending data once a day is fine as well.
I want to know what I have to use to do this API integration - SuiteTalk, RESTlet or Suitelet.
I am completely new to this topic and after a few days of research, I learned that there are 3 options for an API integration with netsuite (Suitelets, restlets and suitetalk which comprises REST and SOAP based web services). I also learned that there are scheduled scripts and user events, but I'm not too clear on the idea.
I need some help identifying which integration option I should choose.
Any and all information about netsuite API integration is appreciated!
I would avoid REST/SOAP. SOAP is outdated, and REST is incomplete and difficult to use.
Suitelet's are for when you want to present your own custom UI to frontend users, like a special new kind of custom form not relevant to any particular record. Probably not what you want.
What you probably want is to design a restlet. A restlet is a way for you to setup your own custom url inside NetSuite that your program can talk to from outside NetSuite. Like a webpage. You can pass in data to the restlet either inside the URL, or inside the body of an HTTP request (e.g. like a JSON object), and you can get data back out from the body of the HTTP response.
A restlet is a part of SuiteTalk. The method of authenticating a restlet is the same for the method of authenticating a request to the REST API. So, learning about SuiteTalk is helpful. The code you use to write the restlet, SuiteScript, is the same kind of code used to write suitelets and other kinds of scripts.
So you will want to learn about SuiteTalk, and then, in particular, SuiteTalk restlets.
this is a really subjective issue.
It used to be that SOAP/SuiteTalk was a little easier in terms of infrastructure and since Netsuite's offerings are ever changing the REST/SuiteTalk might fill this space in the future.
Since Netsuite deprecated the Full Access role setting up integrations almost always involves the integrator having to provide a permissions spec. The easiest way to do that is via a Bundle. For token based authentication (TBA) there also needs to be an integration record from which you need Consumer Id and Secret Tokens.
So as of this writing the set up for SOAP/SuiteTalk and RESTLets is roughly the same. The easiest way to communicate these is with a bundle so if you are a Netsuite dev with a dev account you can set these up in a bundle and have your customer import them.
So equal so far but differences:
SOAP/Suitetalk is slow. IMO not suiteable for an interactive interface
SOAP/Suitetalk the code is all in your external app so changes to the code don't require any changes in the target account.
RESTlets can be pretty speedy. I've used these for client interactions.
Updates require re-loading your bundle or overwriting your bundle files in the target account (with the resulting havoc if an admin refreshes the bundle)
RESTlets give you access to the features of the account on which you are running so that code can run appropriate chunks For instance features such as matrix items, multi-location inventory, one-world, pick/pack/ship, volume pricing, multi-currency will all change the data model of the account your code is running against. RESTlets can detect which features are enabled; SOAP/SuiteTalk cannot.
So really the only advantage at this point that I see for SOAP/Suitetalk is that code updates don't require access to the target account.
Who is making the changes? If it is your NetSuite developers, then your options are SUITELET or RESTLET.
If its your third-party application team, they own the code and the process and do all their work sitting outside of NetSuite - your option is SUITETALK/SOAP. Of course, they need to know something about NetSuite, but your business analyst would be sufficient to support them. As of 2020.1+, there is also support for native REST APIs in addition to SOAP in case you still want to use REST, but not write your own RESTLETS.
As the above comments mention, Suitetalk does perform a little slower than calling RESTLETS. So that maybe one of the deciding factors.
You may consider SUITELETs for integration only if you want to bypass all authentication schemes, by setting the suitelet as public. Highly inadvisable though.
If the third-party application supports REST APIs, you could call them directly from within NetSuite - either from user events or from scheduled scripts.
You can also consider iPAAS platforms like Dell Boomi, Celigo, Jitterbit, etc. These are general-purpose integration platforms, and make connecting one platform to another easy, with minimal coding. If your Company is already invested in these iPAAS platforms for other enterprise applications, then the choice is that much simpler.
I'm looking into using AngularJS for an upcoming project but I am having difficulty getting my head around the views/routing, specifically for an app with only one page.
The page consists of a form or wizard, however I want all data to be loaded on the initial page load (and stored in local storage). This also applies to form elements - no additional requests can be made to the server e.g. for HTML templates (except the submit action at the end of the form). The application will be used offline so the single page needs to cache all required information and handle UI transitions without reloading.
Is AngularJS a good fit for such an application? If so, how can I accomplish the routing required to change views without additional requests - can ng-view and a routeProvider use div's within a single html page? Is this a case for ui-routes?
I've yet to implement such a site but I believe these are slightly orthogonal issues. AngularJS solves the issue of polluting your view with business logic (MVC), it also gives you the means to create singleton services. Further it allows you to extend the vocabulary of HTML with directives to define compound DOM elements or behaviors. All of these elements I believe are helpful in creating a user interface that is loosely coupled via a model and a controller for a view to the data retrieved and stored in services.
Local storage APIs implemented in certain browsers in response to definitions in the HTML5 spec give you the ability to persist data locally and determine when a change from online-offline has occurred, it's covered in depth on this page http://www.html5rocks.com/en/tutorials/offline/whats-offline/
Long and short of it I think AngularJS is an ideal candidate for building rich client side experiences and decoupling the model from the view and the controller (hence giving you the part you need to save separate from the application itself). All that said I'm not aware of any mechanisms built in to Angular to help make this easier, though if you Google a bit for localStorage and AngularJS there is definitely some discussion about it and code available: angularjs and localStorage change event
I have a RAP application which we deploy into a Tomcat instance. The application does some additional stuff during it's first startup.
Currently when the first user opens the webpage in a Browser, it takes quite a while until the application is ready because of this one-time initialization work.
This is bad for usability as the first user needs to wait a long time until this startup-work is done.
Is there a way to trigger or simulate a first session after the Tomcat is started so we can warmup the application and the first user receives feedback quickly?
I tried to do some simple URL-requests via URLConnection to simulate a browser, but it seems the protocol to trigger a new session is non-trivial.
I also tried to use HtmlUnit to request the page with JavaScript enabled, this works to some degree, but HtmlUnit is quite heavy for this simple step.
So is there an official API or at least some sort of workaround that allows me to pre-start and initialize the application?
Unless this initialization requires a UI session (i.e. a user), the configure method of your ApplicationConfiguration could be a suitable place. However, at this point, the ApplicationContext has not been completely set up, so it could be too early. Also, if your application is based on the workbench and extension points, you won't have an ApplicationConfiguration of your own.
Would you mind opening a bug report (http://eclipse.org/rap/bugs) and describe your use case? I think we should provide some kind of hook for applications to setup and clean up, e.g. an ApplicationContextListener?
This is just out of curiosity, as I program games for a living, not web applications.
What is the reason that the Chrome extension API (chrome.* family) consists almost entirely of callback setters? I'm talking about this programming model that at first sight appears to be abusing closures:
// do something with the Tab object of an activated tab
chrome.tabs.onActivated.addListener(function (activeInfo) {
chrome.tabs.get(activeInfo.tabId, function(theTab) {
foo(theTab);
});
});
I'm used to having getters simply return the requested value and just find this interesting. Is this because all these methods (such as getLastFocused here) actually only schedule asynchronous tasks for the browser engine?
I was wondering something similar and came across a good explanation, maybe someone will find this useful as I did:
[The reason for using callbacks in the APIs] has to do with Google Chrome's multi-process architecture. Web pages and JavaScript run in processes which are not only separate from each other, but also from the main browser process which alone has the ability to do things like read & write to the local file system. This is an important security and stability feature for Google Chrome. If calls like this were synchronous, your extension would have to stop everything and wait for the browser process to respond to the request, all the while the user may be trying to interact with the UI of your extension which has become unresponsive. Using asynchronous APIs is more challenging, but it's in the service of the best user experience.
This is from the transcript of this video on the extension API design.
This is a combination of an event handler and some asynchronous actions. In addition, the way scoping works in javascript can be a bit iffy; using closures creates a reliable scope that allows data to be passed about that just couldn't be done in another manner.
From my perspective, one of the reasons, why most methods in the chrome.* APIs are asynchronous, is that extensions usually have to deal with the user interactions. Any asynchronous API in general leads to better application responsiveness. So, developers of the chrome.* APIs simply provide an easier way to write efficient extensions, that will not slow down Google Chrome, making users disappointed.
What is the best practice in handling multiple windows and/or tabs in a web application? What are the pros and cons of a given approach?
I'm not looking for an answer that specifies a particular framework solution. The best practice should apply to all HTTP/HTML based web applications whether they are ASP, .NET, Java Servlets, Struts, JSF, etc
Assumptions:
the application cannot prevent a user from opening a new window and/or tab
HTTP / HTML (how or if it is generated by some framework should not matter). Not Flex, Flash, etc
Should the app try to detect (possibly via a nonce or other technique) that a new window and/or tab has been opened and display some error message?
If the app allows a new window and/or tab, what are the pitfalls (form submissions for one) to watch for and how should they be handled?
I'd say the biggest thing is avoid using "long-persisting" mutable session data (Data that will be hanging around longer than just the instance needed to transfer the data to the next page). This is the biggest challenge I've seen with multiple tabs. What I like to do is store data in the session and then "serialize" that data into the page. When I need that data again I grab it from the page and then store it in the session. That prevents the users other open pages from changing the data.
Your application shouldn't care about multiple tabs being opened. The tab paradigm was developed with the assumption that a page is a page. The biggest thing to do is to understand the technology you are implementing the page in(where there is a potential for data being shared at a global level) and building your pages to be thread-safe(because technically speaking every page request is a thread).