I need to build a PowerApp which presents a daily list of tasks to a user such as number of surveys to complete; within which postcode area etc.
They then want to complete a questionnaire; and store submissions in the PowerApps own Dataverse.
My thoughts are;
Ideally i would want to hook up Microsoft Forms (standard not Pro) so the PowerApp could either link to the form and pre-populate a unique ID or similar? they complete the form; and a Logic App would process into the DataVerse by unique ID. However not sure this is possible?
Other option is i design the Canvas App to complete the survey (similar to the Employee Engagement survey template) - but likely will have 30/40 questions - this would obviously have a direct link to the Dataverse so no Logic App required
Other options?
Thanks in advance
Rich
Stay away from Microsoft Forms for a 30-40 question survey. The conditional logic, error handling, input validation, etc are not robust enough. You'd likely get too much free text to produce any meaningful reports from.
Caveat being: Do external users (outside your Active Directory) need to access the survey?
If so, then Forms is likely the only way to go (unless you want to somehow manage PowerApps licenses for external users).
PowerApps will suffice.
The objective is to create a custom action that returns the RTT from any requested domain. In other words I want to tell the assistant to Ping whatever domain and provide me with the RTT or respond that the server isn't reachable. Whereas I'm not ignorant or unable to research and apply results, I've not seen any similar project or a web-hook that would be easily applied. I've got some IFTTT experience and have created Glitch projects that have provided me with additional utility for the assistant. Honestly ''created'' is an overstatement, implementation was just a little step above script-kiddie abilities. The result was that the assistant now provides me with more functionality to control my media center on a Firestick than Amazon's skill does.
So, my assumption is that this is a pretty low level skill. I have no interest in this being anything other than a personal action. That said, I can handle invocation and all the other overhead necessary for human interface...etc but would surely appreciate assistance, references to similar projects or a helpful overview of what one thinks is the best method to accomplish the task.
If you are reading this and wondering why I posted here, please provide me with a more appropriate or topical forum location.
TIA
We are already using PAS182 for some of our projects as the standard for building Smart City. Our customer has asked to follow the FIWARE standards. Just want to understand what is the difference between PAS182 and FIWARE. Can you please help us compare the two. Thanks!
PAS182 is a defined standard for data modeling within Smart Cities - it describes the relationships between various concepts so that data from local authority X should hold to the same data model definitions as data from local authority Y.
As the BSI web page states:
The smart city concept model (SCCM) provides a framework that can normalize and classify information from many sources so that data sets can be discovered and combined to gain a better picture of the needs and behaviours of a city’s citizens (residents and businesses).
FIWARE is concerned with the interoperability of the transfer of context data. Specifically the current state of a system (i.e. the now) is held within a context broker and all elements surround a context broker must interact with it using a defined standard NGSI
Therefore there is no conflict between the two - you can base your data models on the terminology defined in PAS182 and create your own entities by communicating with a context broker using NGSI.
A little background: I have the opportunity to present the idea of a public API to the management of a large car sharing company in my country. Currently, the only options to book a car are a very slow web interface and a hard to reach call center. So I'm excited of the possiblity of writing my own search interface, integrating this functionality into other products and applications etc.
The problem: Due to the special nature of this company, I'll first have to get my proposal trough a comission, which is entirely made up of non-technical and rather conservative people. How do I explain the concept of an API to such an audience?
Don't explain technical details like an API. State the business problem and your solution to the business problem - and how it would impact their bottom line.
For years, sales people have based pitches on two things: Features and Benefit. Each feature should have an associated benefit (to somebody, and preferably everybody). In this case, you're apparently planning to break what's basically a monolithic application into (at least) two pieces: a front end and a back end. The obvious benefits are that 1) each works independently, so development of each is easier. 2) different people can develop the different pieces, 3) it's easier to increase capacity by simply buying more hardware.
Though you haven't said it explicitly, I'd guess one intent is to publicly document the API. This allows outside developers to take over (at least some) development of the front-end code (often for free, no less) while you retain control over the parts that are crucial to your business process. You can more easily [allow others to] add new front-end code to address new market segments while retaining security/certainty that the underlying business process won't be disturbed in the process.
HardCode's answer is correct in that you should really should concentrate on the business issues and benefits.
However, if you really feel you need to explain something you could use the medical receptionist analogue.
A medical practice has it's own patient database and appointment scheduling system used by it's admin and medical staff. This might be pretty complex internally.
However when you want to book an appointment as a patient you talk to the receptionist with a simple set of commands - 'I want an appointment', 'I want to see doctor X', 'I feel sick' and they interface to their systems based on your medical history, the symptoms presented and resource availability to give you an appointment - '4:30pm tomorrow' - in simple language.
So, roughly speaking using the receptionist is analogous to an exterior program using an API. It allows you to interact with a complex system to get the information you need without having to deal with the internal complexities.
They'll be able to understand the benefit of having a mobile phone app that can interact with the booking system, and an API is a necessary component of that. The second benefit of the API being public is that you won't necessarily have to write that app, someone else will be able to (whether or not they actually do is another question, of course).
You should explain which use cases will be improved by your project proposal. An what benefits they can expect, like customer satisfaction.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm working on a web based application which uses a JSON over HTTP based API to communicate between the server and the client. The goal being that multiple clients can be developed with different goals (online web client, offline desktop client, or third party created) using the same online data to be shared through this web service.
Right now the communication between the client and server is sent via POST only through a system that works well. I read quite a bit of information about REST and being RESTful with HTTP using PUT, GET, POST, and DELETE. I could separate my API into these different categories, but it means more code and some changes to the API.
My question is: how important is it for a HTTP based API be RESTful? Is it a recommendation, an option, or a near necessity?
Thanks in advance.
As a die-hard RESTafarian I'd say use HTTP (the REST protocol in question) to its full extent. Why? Well, I'll show you two snippets from an email exchange I had yesterday with a good friend of mine who's seriously clever (and used to be a professor of IT, still lectures, still kicks ass wherever he goes) ;
Yesterday I passed an important
milestone for my mappodrhom
application: I can now launch
long-running background computations
into a worker pool. When they finish,
the workers POST back their results
directly into the REST resources.
Which triggers more background
processing, all controlled by a
dependency graph.
And the interesting aspect is that
this RESTful backgrounding is
actually independent from my
particular application. But I am
currently too tired to completely
grasp the consequences :-)
The consequences in question are huge (it's a REST framework with lots of little stacks and events and services and apps, all with their own discoverable URIs, all with the same unified interface), and in terms of extensibility and scalability it is simply unmatched in its simplicity. If your application is a dinky little thing that will never travel places or meet hot chicks, yeah maybe you don't need it. But then, I've said the same, and all of a sudden found myself on a train to Paris with a cute girl that is a secret spy for the Russians, and well, one thing led to another...
Here's my reply, with some of my own experiences ;
I think this sounds (pardon my French)
f***ing awesome! I'm experiencing
similar things with my own REST stuff,
where because the middle layer is so
thin and transparent, I can just
extend things the way I need them
without worrying too much about the
infra-structure. It's such a freedom,
such a kick-ass cool thing that my
brain is about explode, and a
worrisome curiosity to why more aren't
doing it?
In short, doing REST only half-way is just like not really doing it at all. You're just shifting your stuff over a different pipeline, missing out on a simplified API into a state-machine, semantics- and implementation decoupling at the core, working with the principles that built the net (and hence I'd say you've got rather proven ideas behind you), the unified interface, and having URIs as part of your modeling.
I know it's popular to say that you can pick and choose, that it's all just options. It's not. REST only makes sense by using it fully, but as to convincing you to actually stretch your brain a bit further and do something clever, I can only dare you to cut through the FUD (that it's all about RPC, only GET and POST necessary, you don't need it all, equivalent to JSON, SOAP and other ilk, etc.), and be smarter about how you make applications. Yeah, I dare you all!
Unless you are going to take advantage of hypermedia then I wouldn't bother trying to conform to the REST constraints. Hypermedia is the piece of the puzzle that makes the system greater than the sum of its parts.
You are free to pick and choose which of the REST constraints you want to respect in your architecture, just note that to be able to call the end result RESTful, the only optional constraint is "code-download".
It's an option amongst several for exposing a web application as a web service with a well-defined API. Other options include:
No API - The application has no real way to be used as a component in other distributed systems
SOAP - An XML format for defining API remote calls
JSON - A compact format for information exchange that can be built on to create a custom API format (or used to build a REST system if you wanted)
Many other forms of remote procedure calls and information exchange mediums.
REST has a nice ideal behind it, but that doesn't mean you have to provide a REST API for your application. If the gain isn't worth the extra effort, don't bother.
It is a recommendation. I am glad you did not go into how RESTful you need to go into as there is something called Hi-Rest and Lo-REST. You can get more information from googling. Some industry veterans I know do not much care about this, but I do find staying as close to html and http will help you in the long run and simplifies many things.
I would submit that it's a nice to have but not a must. In my experience adding this architecture increases the scope and complexity of the project, but it does add a degree of elegance to the whole. I would say if you've got the time and budget on the project, go for it, if not don't worry about it.
One (of the many) things to consider with service API's is the ease in which they can be consumed by your end user. REST is gaining a very strong tooling presence.
By far the largest dev group out there is the .NET dev group, and with ADO.NET for services (Astoria) consuming REST using Linq is very simple and very elegant.