In our experience with other APIs there is usually a test/private mode and then after the app is approved it can go into live/public mode.
After we create an application based on Microsoft Graph / Outlook REST, what is the process to get the application live/public available for use by our customers and how long does it take? Or is it already live?
Your question isn't really specific, so I'll just answer the general question.
Everybody can create an application for the Microsoft cloud. There isn't a test environment, so every application is live the moment you create it (and switch on multi-tenant). It is always up to the user (or tenant admin) to grant your application access!
Microsoft does however offer various ways to get your application under the attention of a much larger audience. And to get your application in such a marketplace they have various review/test/... processes in place.
Related
We currently have a web application which requires manual intervention in order to initiate the transfer of data from Azure Active Directory (via the Microsoft Graph API) to a local SQL Server database instance for archival and reporting purposes. This manual process is often run multiple times per day.
Our goal is to automate this data transfer process through use of a Windows service application; however, we have encountered an issue with instantiation of the Microsoft Graph client. The vast majority of the documentation available seems to presume the use of Microsoft Graph with a user interface (which the service app doesn't employ). Methods which work quite nicely with the typical MVC-based C# web application don't sit well within the more limited confines of a Windows service app.
Is this type of automation possible? If so, is there any sort of documentation available regarding the use of Microsoft Graph within a Windows service app?
Any assistance is greatly appreciated.
There is a documentation where is described how to call Graph API from a background service or daemon app without any user interaction. The same way will work for Windows service.
Documentation
Get access without a user
We are developing some REST api's for internal use. To test these microservices we are toying with the idea that every service has a sandbox mode so we can do integration tests that are as close as possible to the real deal.
To see if this path is worth trying we are looking for documentation / best practices on how to manage this sandbox and how to implement this internally. When we look for the keywords Sandbox, REST API and Best Practices we only find how to implement as consumer of existing sandboxes.
So does anyone have some documentation / links in how to tackle this problem and what the pro's and con's are of the different ways?
Kr,
Thomas
I'd say there are two ways to proceed:
Basic: keep a separate sandbox instance of a service. You always deploy a new code to this instance first and run automated/manual tests to verify if everything works fine. A datastore could be a snapshot from the production data or artificial testing data. I would rather we have a "Snapshot" but it depends whether it is applicable in your particular case (privacy etc.)
Advanced: I spied this technique on Facebook Marketing API. This API provides an interface to set up and launch advertising campaigns. They didn't provide a sandbox api for testing purposes (at least last year when the system I was working on had been integrating with Facebook). However if you use a keyword "test" in a name of a campaign or an adset (key entities in the ad world) they would never launch and spend your money. You can try extend this concept on your particular domain and run tests on (or very close to) your production
Hope this helps
I need to develop a chatbot with these properties:
Platform - Skype for Business On-Premise
Function - Replies to user queries by looking in various knowledgebases (Multiple Platforms - Databases, Web APIs, etc.)
Basic textual conversation to begin with and will gradually evolve to send attachments
No calls/videos, just chat
Will be hosted on an external server with organisation VPN
A simple sip will be created for the chatbot which can be pinged by any user. I should be able to get this through to our IT dept.
Limited time for development
Scalability is an essential requirement but the organisation is fairly new to this, so they might be patient and allow me to make mistakes
My research has led me to these possible approaches:
SfB SDK - I have rejected this approach because it requires the client to be running at all times and doesn't seem to be scalable
UCMA with Application Endpoint - Haven't rejected this approach, but seems like I'll not go ahead with this because creation of Application Platforms seems tedious and requires me to make a lot of SfB server related IT requests
UCMA with User Endpoint - Great affinity towards this. I have experimented Tom Morgan's (thoughtstuff.co.uk) stuff and this seems like something I can start off right away
UCWA with Application Endpoint - Rejected this approach, because UCWA (from my research) appears unsuitable for On-premise and the setup also seems time consuming
UCWA with User Endpoint - Haven't rejected this approach, but I'm not sure if the Web API way is really a good approach for On-premise platform
I'd like to ask how am I doing so far, but that seems too vague
What would you suggest is a good way to achieve this?
Also, can someone be patient enough to reply the drawbacks and advantages of each approach for my use case. I'd like to make an informed decision and not reject any approach, just because of a misunderstood overhead
I have been asking around in my organisation and other circles.
And since I am not receiving any quick responses, I'll keep adding what I have learnt.
This way a person in the dev community will have a log of how I went with this.
UCWA is better suited for S4B online (compared to on premise) and is generally used by people who are comfortable with RESTful and have low familiarity with .NET development
UCMA is apparently THE WAY to go and for any on-premise bot requirements, preferably with an application endpoint.
So for our development, we are starting with UCMA user endpoint so that we can deliver a basic start as a version-one
And meanwhile we shall also get in touch with the IT department and Lync administrators for creation of Application Endpoints
Once we have this the same functionality that we had with the user endpoint will be copied over to the Application Endpoint version
Keep watching this space for further updates
There are a ton of online CMS services out there. And a ton of (new) backend-as-a-service products too. But I can't seem to find what I am looking for.
I am building an app for a client. The app contains data about shops, products, and more. The client must be able to update this data (and not just one person: each shop manager needs to be able to log in and edit the data for their own shop). And of course the app must be able to access this data.
Client edits data online
This has to be extremely user-friendly and completely online. I don't want to sell my client something where they need to install stuff on their server. I don't want to sell them something that's accessible online but looks like phpMyAdmin.
I want a shop owner to be able to go to a webpage, log in, and then see a pretty UI where they can edit the data for their shop. The back-end needs to have a pretty front-end that's auto-generated for whatever data this particular shop owner is allowed to edit.
So there are two bits: storing data in the cloud in such a way that it can be accessed by the app (which I am building with Titanium), and allowing the client to log into the backend and edit the data in a non-tech, user-friendly way.
Here's a list of things I tried...
Backend-as-a-service
Services with a great back-end, but without easy auto-generated data editing website:
Appcelerator (Titanium) Cloud Service
Amazon EC2
Stackmob
BackBeam
WebVanta
Parse
API o Mat
ShepHertz Cloud42
Kii
Online CMS
Services that provide a nice way for clients to edit data, but no easy way for apps to connect:
CloudCMS
(and many others I'm sure)
It's insane that no-one seems to be providing the cross-breed of BaaS and online CMS. So many people are building apps for clients, and so many clients are not tech-savvy and are reluctant to get a special server and host database software they don't understand. Why does this not exist? What am I missing?
With apiOmat it's easy to create your own data-editing app for e.g. with JavaScript SDK and HTML. Or you send a feature request so that they build a module for your preferred CMS.
As you mentioned, Cloud CMS is a really good option (disclaimer: I'm one of the founders). The product provides an enterprise content management backend and an API that lets you plug in some really powerful features right into your mobile apps.
This month, we released a brand new user interface which provides much of what you're asking about. Instant forms, document libraries, search and workflow all in one place.
You can check out Cloud CMS here: http://www.cloudcms.com
I completely agree with your assessment particularly with respect to the last mile (getting the final app built). It's kind of the wild west out there and the strong technologies are still proving out.
You mentioned Titanium - that's a good choice. I also quite like the Ionic Framework (http://www.drifty.com/). It's a step in the right direction.
I have a couple of questions regarding IBM Portal Portlets.
I have just stumbled into the realm of Portlets - and as far as I am concerned was dropped into the deep end. Having to work on a IBM WebSphere Portal 6.1
We are still in the evaluation stage - and three things that I haven't been able to find clear answers to yet.
Database - is there one single Database that also gets used by the installed Portlets - or do you configure DB individually on a per Portlet Basis?
Authorization and Authentication - how can a Portlet get hold of the User and the rights the user has?
Are there any known constraints in using JSR-301 compliant JSF Bridges instead of bog standard Portlets?
Thanks in advanced.
I haven't used Portal 7 yet, but I have used pretty much every other version, so my apologies if you are using 7 and this information doesn't fit exactly.
1) Database: when you install portal, you configure a database it uses to store portal configuration (and sometimes user rights as well, although this aspect can be set up using a custom user registry like LDAP). If you don't have an already dedicated DB, Portal will use its packaged DB, Cloudscape/Derby. This DB can be completely separate from the DB that the portlets use to manipulate data unrelated to configuration. E.g. if your portlet is displaying inventory for a bike shop, the DB holding that info can be accessed in the normal web application way through a datasource set up in the WAS GUI.
2) For a lot of scenarios, your portlet doesn't need to know the user's rights, it won't render the portlet unless the user has been assigned the correct rights via Portal Administration. But in the cases in which you would need to know the user's rights, they can be accessed via the Portal User Management Architecture. Here's a good whitepaper on the subject: http://public.dhe.ibm.com/software/dw/websphere/PUMA_scenarios.pdf
3) Known constraints? You may have to google for that specifically, but I will say that unless you use IBM's custom JSF bridge, there may not be a lot of support from IBM's technical issue team if you come up against a problem. However, the support guys are usually pretty helpful, I find. Don't let that stop you from trying though :)
The two resources that I use pretty exhaustively are the InfoCenter http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp and the developer forums on IBM Developerworks.
Best of luck, and welcome to the dark side!