I'm very new to AD LDS and experienced but not qualified with SSAS, so my apologies for my ignorances with these.
We have a couple implementations where we expose SSAS via an HTTPS proxy (msmdpump.dll) and currently we have a temporary domain setup handling this (where our end-users have a second account+creds to manage because of this = non-ideal). I want to move us towards a more permanent solution which I'm thinking of moving all authentication to AD LDS for our web apps, SSAS, and others. However, SSAS is where I'm concerned about this.
I know SSAS requires Windows Authentication and to play nicely, and that this ultimately means Active Directory will be involved.
Is there a way to get this done with AD LDS instead of having to use a full AD DS implementation? If so, how?
Nope, SSAS requires a full AD account for authentication.
We ended up just going with full AD-DS instead of AD-LDS.
Related
Can AD Data Connector API calls impact other currently executing APIs?
The existing projects will remain in 360 and only new projects will utilize ACC.
Here is our potential scenario:
ACC will be using the DC API approach
360 API pipeline continues in tandem with ACC API based on amount of work to transition dashboard/reports
Does anyone have any experience or information?
Will this cause resource issues like throttling, data locking, etc. OR are they actually two different data capture streams and will Not impact each other?
Searched on AD but didn't see any specific information.
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've developed a Windows Store App which is ad supported. After struggling quite a bit with the actual implementation and testing locally, I (think I) managed to make it work - using the test ids provided by Microsoft my local tests showed the example ad.
After I uploaded the app to the store, however, I get the NoAdsAvailable message (I did use the correct ApplicationId and AdUnitId, not the test ones), indicating that there are no ads of the specified category available at my geographic location (it is my understanding that this is how Microsoft differentiates which ads should be shown where).
Now what I would like to know is which of the different ad rotator solutions is recommended to be used - or is this too dependent on where I live?
I've found the following three alternatives:
AdRotator
AdDuplex
AdMob
Does anyone have any experience in using them? What are the differences? Just using the pubCenter ads from Microsoft doesn't seem to be the best option as various posts I've found indicate.
What you've discovered is that ad providers won't always have an ad available to show every time you want one. This is called the "fill rate". Depending on the ad provider, the app category and where in the world the person viewing it is, this can vary dramatically. Somewhere between 10 and 40% can be seen as normal.
Your intention to use a tool to include support for multiple ad providers is a common approach to this scenario.
There are 2 tools that you can consider: AdRotator; and AdMediator (video)
AdRotator is a mature, community provided service which supports a wider range of ad providers.
AdMediator is newer and provided by Microsoft. It is integrated with the Windows Dev Center but is only available in limited locations.
Both allow you to set a number of ad providers to use on a fall-back basis. If the first doesn't have an ad it tries the next, and so on.
AdDuplex is different to PubCenter, AdMob or the other advertising providers in that it is a cross promotion service. You show ads for other apps and they show ads for yours. For every 10 ads you show, 8 ads are shown for your app. The other two spaces are sold to fund the service.
Due to the way it works, AdDuplex always has an ad for you to show, so even if you can't show an ad that will earn you money, you can show an ad that will lead to an ad for your own app being shown. Hopefully this will lead to more users for your app which will in turn lead to more money earned from ads shown in the future.
Whichever ad providers you use, it makes sense to always include AdDuplex as a final option with either AdRotator or AdMediator so that, as long as you have a network connection, you are always making use of the space in your app that you've allocated for ad space.
Disclaimer - I'm an advocate for AdDuplex.
Can anyone give me a brief rundown of how Facebook and Google Talk work, are there persistent connections involved similar to the classic Java based chat systems whereby a server manages the connections and directs messages to the necessary destination or are they stateless? I'd like to create something similar to these but I'm not sure where to start and if I need to have custom services running on a server I may have to rethink my approach.
I'm not after a full-blown explanation but I am interested to know if there's a stateless approach that doesn't require services running on a server. If Html5 is required that's ok.
Both use the Jabber protocol: http://www.jabber.org/
So, going from the discussion here where I was soundly rebuked and for good reason. I want to give clients unique code snip-its that allow me to change a banner ad without requiring them to FTP anything or change their site. Security is clearly a concern. The ad is code, not an image, as we are testing multiple ad networks. So, to summarize:
-client gets a couple lines of code for each place on their site an ad is placed
-I insert code from ad network (adsense, etc) or our own ad for the location without the client needing to lift a finger
-no security breaches or impact on client site
What would be the best approach to this problem? Minimizing developer time and maximizing security...
One of my clients uses Adjuggler to do exactly what you are talking about. The ads are administered by the agency that sells their ads, they just put a little snippet of Javascript on the site and the ads load dynamically based on the settings and campaigns that the agency sets up.
http://www.adjuggler.com/
The best and quickest solution would be to install an existing advertisement framework that will allow you or your client to add, remove and edit ads through a web interface. There are also a number of CMS suites (drupal, CMSMS, Tiki, etc) that either support ad management natively or have ad modules available. Either solution would require no code be written and allow powerful advertising options.