I am planning to make a soft phone JQuery plug-in with the new Skype web-SDK.
It is still unclear to me if the web-sdk depends on UCWA or that it can be used with the classic UCMA as well, and does it require Office365 for on-premise UCMA / UCWA machines like a cloud hosted instance.
Also what is the current availability of UCWA?
Thanks in advance.
Has been recently announced, during Build 2016 conference, that UCWA as well as Skype Web SDK is now available also for Office 365 customers.
UCMA is still only available to customers with on-premises Lync 2013 / SfB installation
Refer to this documentation: Skype Developer Platform
I may have found the answer here skype document.
What’s worth mentioning here is that UCMA is still not supported in Skype for Business Online, and at launch the Skype Web SDK will not be supported Online. Also, only Basic support for the Web SDK will be available in Lync 2013. I don’t know what that means exactly, but when I find out I’ll let you know!
Still a bit vague for my taste
Enzo - Your reference is more than a year old. We have launched Skype Web SDK for online. It depends on UCWA, which is also now available for online.
Related
We have Skype for Business Online 2016 and we would like to integrate our bot (based on rasa) which has currently no built-in integration for Skype. Custom channel will be implemented in Python.
After doing research it seems that UCWA is the way to go if IM need to be send and received between our bot and S4BOnline. See also: https://learn.microsoft.com/en-us/skype-sdk/skypedeveloperplatform
The documentation states it applies to S4BO2015 and not sure if S4BO2016 is supported as well. Can somebody confirm?
When you see this on the website:
Applies to: Skype for Business 2015
This only specifies version of SfB Server for which it is applied (as for now, Skype for Business Online runs Skype for Business Server 2015 under the hood). I don't think you'll find anywhere in the docs:
Applies to: Skype for Business 2016
What you are confused about is the version of client The client version is (not sure if this is official naming but that's how they're usually called):
2015 for users with Office 2013 and Skype for Business UI applied
2016 for Office 2016 users
While checking compatibility you need to verify that Skype for Business Online is supported and if you develop any client-only solutions/add-ons you might want to make sure that Skype for Business 2016 is supported.
Just a side note: keep in mind that Skype for Business Online is going to be replaced by Microsoft Teams (check this page for more info) so maybe it's worth to keep that in mind while choosing the technology for your new bot.
Some links that might be helpful to start:
Developing UCWA applications for Skype for Business Online
Sending IM using UCWA
Example of UCWA-based bot for Skype for Business Online
I've been researching for quite good amount of time about how to interact with Skype, meaning how to send and receive Skype messages from another application that I'm planning to develop.
I found a lot of things which made me confused. There is Skype API mentioned and used by some libraries (like SkPy), and there is Skype Web SDK, SkypeKit, and others.
When looking on the official Skype dev website (https://dev.skype.com) nothing about these is mentioned, and looks like the Microsoft Bot Framework is where MS is moving everything to (or at least that is what I got).
My question is, what is the current situation now regarding this topic? Is it still safe to build a solution on such libraries as SkPy (which uses Skype HTTP API that I could not find a trace of in the Skype's official docs!, but still, I tested and it's working!). Or I should just think of MS Bots? And is Bot a suitable solution for such use case in the first place? (I feel it's not meant to do so).
Hopefully will get some hints.
I'd like to create a simple server service that can perform the following tasks:
Retrieve presence info for specified user(s).
Send message to specified user.
From what i've been reading, and because i'm siting server side I could choose to use UCMA 5.0? But i'm seeing a lot of push of the new UCWA SDK and working with the UCWA rest services. Is there any particular reason why i would use UCWA server side rather than just the UCMA API? I read that UCWA will, in the future, be support by Microsoft for Cloud --- Any input and experiences shared on this would be great.
Thanks, mike
UCWA will be at some point be supported in Office 365 indeed. So if you create an application with UCWA you can expect it will run in the next future on your S4B On-Prem as well as on Office 365.
I have to say anyway this support for UCWA on 365 is already long awaited, and still there's no official announcement about availability date.
A very good reason to choose UCWA instead of UCMA, also in case of server automation, is the much simpler deployment of UCWA (UCMA deployment is quite tough).
UCMA must run on a Windows Server OS which joins the S4B farm basically (thus sits in your DMZ)
UCWA can run on any device that 'speaks' HTTP. Your UCWA App can run, for instance, on a Raspberry Pi
I think this is a huge difference, for sure it is for your system administrator
Old thread, but in my experience, writing server-side code with UCMA is somewhat easier than trying to use UCWA - and all that UCWA really is is a UCMA application sitting on your Lync/S4B server with a REST wrapper.
For the fairly simple use-case you've described, you could write the service as a client-endpoint UCMA application, which avoids the rather irritating Lync/S4B topology changes and deployment headaches that Massimo alludes to for a TrustedApplication. In this configuration, you are essentially just a third-party client, and you provide the credentials to sign into Lync/S4B as a specified user. Under this scenario, the only requirements are that the server running your application needs to be joined to your domain, run a 64-bit Windows OS, and have the UCMA runtime installed.
Some sort of API support for Skype for Business on Office365 is badly needed. There was some promises of a UCMA-like SDK for Office 365, but it has been more than six months with no hints of an actual release.
I have a rails app that takes care of all the bank transactions for us. Our accountant wants all those to be automatically imported into Quickbooks Pro (either online or desktop version).
I've read about Web Connector and Transaction Pro Importer, but I feel like I don't have enough info to make a decision. I'd appreciate any advice!
Thanks!
For QuickBooks for Windows:
If you're a developer, and you're comfortable with developing with some SOAP components, the Web Connector will be a good direction to go for you.
There's some pretty decent Web Connector Ruby gems out there already:
https://www.google.com/search?q=ruby+quickbooks+web+connector
If you're not a developer and/or don't want to develop something yourself, Transaction Pro makes things relatively easy to import/export.
For QuickBooks Online:
For SaaS applications, the QuickBooks Online APIs are very good. For non-SaaS applications, you have to use the qbXML gateway for QuickBooks Online, which is somewhat limiting sometimes. In your particular scenario (you're not a SaaS app allowing your customers to connect their QB files to your app) you'd be better off with QuickBooks for Windows.
I know this is repeated question. I read almost all the threads , googled a lot and became more confused. I read Microsoft Mobile Internet Toolkit (MMIT) is not used anymore and Windows Mobile 6.5 Developer Tool Kit is widely used .
Requirement:Develope and publish websites for mobile phones.
Envoirnment:VS2008/.net 3.5
I am new to mobile web application development. I want to know how to start ,what are the frameworks i should know/download,sample websites or articles..
Thanks,
Vanitha
If you want to create web applications for mobile devices using microsoft technologies check out this site:
http://www.asp.net/mobile
It has simple how-to.....
If you're going to invest in a new skill, I'd focus on iPhone and Android development - they're far more widespread than windows mobile.