I am planning to build a similar chatbot built by Microsoft team for a super mall in china (https://microsoft.github.io/techcasestudies/bot%20framework/2017/06/21/CaaP-SuperBrandMall.html), I have below requirement :I am using visual studio 5 for Bot Framework.
I want to get the details of different clothes available in the store
I want to fetch the data from Azure SQL ( Already have data in csv format)
I want to connect LUIS too
Integration with Skype
I have the following queries:
Which type of dialog is used here? Can I do it with only FormFlow dialog?
Integration of Bot framework with Azure SQL( Mainly fetching the details of location of clothes for particular ocassion,gender,brand in mall)
What modification is required in Model folder in bot framework?
Integration of LUIS
Please help me with this if anybody can suggest/add.
Thanks in advance.
Which type of dialog is used here? Can I do it with only FormFlow dialog?
FormFlow suits for handling and managing a guided conversation, based upon the specified guidelines (or collecting information from the user).
Based on your scenario and requirements, your bot would have more complex logic, integrate with LUIS service (recognize user intent and then do different operations based on what user said) and perform database etc, I recommend using dialogs to manage conversation flow, which would be more flexible.
Integration of LUIS and Integration of Bot framework with Azure SQL
In your bot application, you can create&use LuisDialog to integrate with a LUIS.ai application easily, which could help detect what a user wants to do by identifying their intent, and then you can get the matching entities from LuisResult within intent handler method in LuisDialog.
After you know user intent and the matching entities, you can call different methods or child dialogs to do different business logic or operate database to get location, stores or products etc details.
Note:
LUIS Bot Sample
Best practices of building LUIS app
Related
I am managing a web application which have to be integrated with other systems such as SAP/Oracle ERP. I am pretty familiar with the middleware method of data integration where I use my stored procedures to read/write data from/to the middleware database and the other system(SAP/Oracle ERP,etc) use their methods or custom applications to read/write their data from/to the middleware DB.
Now I know that these companies like SAP have their own API for integration.So i want to understand how does API based integrations work. Can you guys please help ?.
One of the best resources for SAP integration is the SAP API Business Hub: https://api.sap.com/. You can use it to search for predefined APIs that are available within the SAP system. To use these APIs, you will need to configure and activate them in the SAP system. These predefined solutions are designed to be used for a particular business process. For instance, to send/receive employee data for HR records, or to send/receive purchase orders. SAP aims to provide sufficient APIs that almost any integration needs can be met with their predefined solutions.
Regarding the types of API solutions SAP uses, SAP allows for the creation and consumption of OData, an open protocol for REST based APIs. This blog series contains a good introduction to how OData is used in SAP: https://blogs.sap.com/2016/02/08/odata-everything-that-you-need-to-know-part-1/. OData uses HTTP requests, so the two systems can interact using the standard CRUD operations (create, read, update, delete). Two important transaction codes to work with IDocs are:
SEGW (gateway service builder): create OData services
/IWFND/MAINT_SERVICE (activate and maintain services): activate and query the services
In addition to this, as you mentioned, SAP has its own API technologies. Two key SAP technologies for integration are:
IDoc (Intermediate Documents):
This is a document format that you can use to send data to external systems (outbound) and receive data from external systems (inbound).
You set up partner profiles for the system you are sending data to (t code WE20).
There are predefined IDoc types that define the data contained in the IDoc (this is the 'basic type' and 'message type'). IDoc data is organised into segments and, for a given IDoc type, you can append the segments so that only the specific data you require is sent.
You will need to map the data structure from the outbound and inbound systems using your middleware.
For a detailed guide to IDocs I strongly recommend the ALE (application link enabling) e-book on the SAP Learning Hub if you have access. You can use t code WEDI to browse the relevant ALE t codes.
BAPI (Business Application Programming Interfaces):
These are similar to function modules, but, unlike function modules, they can be called remotely. Like IDocs, they use RFC (remote function call).
BAPIs can be executed using SE37. You need to set up a test sequence (Test -> Test Sequences) because BAPIs do not automatically commit. Give the name of the BAPI, then 'BAPI_TRANSACTION_COMMIT'. Then execute the sequence to use the BAPI.
Many pre-existing BAPIs are already in SAP. You can browse them using t code 'BAPI' (BAPI Explorer).
Please see this guide for further information on BAPIs and for instructions to make your own BAPI from scratch. https://www.guru99.com/all-about-bapi.html
I have an idea for a web app project, however, due to not having any programming knowledge, I'm first asking here for directions. Essentially, I wonder if the idea is realistic and what the most effective way could be for me to tackle it.
I want to combine several open-data sources, some in the form of API's (e.g. Google maps), others in the form of statistics in Excel sheets. Like a Mashup of different sources? The idea is to use the data to perform some data crunching and in effect provide some insights from this data in an aggregated way. I have previously played around with dashboards during an internship and I am attracted by the idea to maybe produce a Single page application for my idea with some visualisation. Any thoughts on this?
I have looked at the following services online, but I have no idea if they can help me produce a web app which aggregates different data sources and that allows for nice presentation:
Zoho Creator,
QlikSense,
Sproutcore,
Caspio
Any thoughts on this are highly appreciated!
Best regards
If you’re not a developer and would like to get started immediately, then you could get started by signing up with Zoho Creator. Its intuitive yet easy to use builder lets you setup web app in minutes.
Regarding your query for aggregation from different data sources, Zoho Creator provides REST API that allows you to access external data sources to interface with your web applications.
Zoho Creator allows you to setup the perfect web-app on a secure cloud with admin level access to handle the necessary permissions and manage data.
You can customize the Reports in your Zoho Creator application using Report Settings to suit your needs. Web-App can be created by converting a CSV/Excel into a full-featured Web DB / app in seconds.
You can check out our help videos or register for our upcoming webinar to know more about Zoho Creator.
Happy Building!!
Disclaimer: I work for Zoho Creator
Kindly, can anyone differentiate between System api and Process api?
Please provide answer in Generic terms, as i am unable to find on internet.
A system api abstracts from an existing system. It talks to the system in the language of the system (e.g. SOAP, direct Java calls, SAP calls, etc.). To the outside world it offers a clean API (usually REST with http and json). When you do a good job implementing your system api, you can exchange your existing system with a different/new one without changing the api of your system api to the outside world: Just implement a new system api with different adapter logic.
A process api should talk REST on "both ends". It calls one or several system apis to do its job. The process api orchestrates different jobs.
When you need more information, do a search with "api led connectivity"
A System API is a layer you build on top of a system, which handles all system specific connection quirks and settings. It then exposes these resources and it's logic in a standard format (usualy REST but you're free to choose something else like SOAP) to the rest of your API's. Like Roger Butenuth states:
"When you do a good job implementing your system api, you can exchange
your existing system with a different/new one without changing the api
of your system api to the outside world: Just implement a new system
api with different adapter logic."
A process API is where you keep your logic and orchestration, it does not 'talk' to end systems directly but instead connects to system API's to get it's data.
A process API should idealy only talk REST on both sides and can aggegrate data from multiple systems.
An example of a complex process API would be an "items you've ordered" API which takes in a user id as it's input, then talks to the system API of a CRM system to get the id used by the "order history system API".
However this API might only return a list of orders without any article information besides an article id. So our Process API then enriches this list with Article information fetched from "article information system API" with the id from the list.
I know it's out of the scope of the question, but for the sake of completeness i'l shortly explain the third variant as well:
An Experience API can be seen as a doorway into your API network, every (type of) client has different information needs and can communicate in different protocols.
It is the Experience API's responsibility to provide ALL the information required by a client in a format they support.
This takes the responsibility away from a client to know where the information needs to be fetched from.
(Customer info from CRM, Order info from proprietary sys one, Article info from article DB)
This concept of design has as a bonus that if when for example, the mobile app your company is making, gets some new functionality which requires extra data.
You can update the "mobille app experience api", which would leave your "superexpensive IBM Experience api" unchanged. Cutting down on development costs as you don't need to implement any changes in your other api consumers which would be the case had you had only one api.
I think the main difference is where you are implementing business process and rules/logics.
System API, within the scope of your design, are atomic APIs which will be used to construct higher level API (experience APIs). Process API is the orchestration layer where you can use Mulesoft flows to implement business process or logic.
System APIs do the heavy lifting work of CRUD operations.
Process APIs focus on business logic
System API's are underlying all IT designs are center frameworks of records that are regularly not promptly accessible because of its many-sided quality and network concerns. APIs give a method for concealing that many-sided quality from the client while uncovering information and giving downstream protection from any interface changes or legitimization of those frameworks.
Process APIs exemplify the fundamental business forms that cooperate with source and target frameworks or channels through an arrangement of framework APIs. For instance, in a buy arrange process, there is some rationale that is regular crosswise over items, geologies and retail channels that can and ought to be refined into a solitary administration that would then be able to be called.
And you will get some more clarity from this article https://dzone.com/articles/api-the-backbone-of-the-software-industry-know-how
System API and Process API will be part of API led connectivity.
System API is like awrapper service to either a main data base or saas platform
Process API involves application logic to validate search or query parameters
An application-programming interface (API) is a set of programming instructions and standards for accessing a Web-based software application. Could someone explain to me in case of Google maps or Youtube which is the API and which is the software application? Are both visible to us and how? I know there are tons of articles out there, however I cannot clarify the above. APIs are like the waiters that transfer data among different machines. Okay, which exactly is the Google maps API and how do we call/use it? And which is the Google maps software application which is accessed by the API? When we write for example http://maps.google.co.uk/ do we call the API? My query may seem silly but I cannot find a good answer for that.
An application-programming interface (API) is a set of programming
instructions and standards for accessing a Web-based software
application.
Firstly, an API is not just for web-based software. Even your computer's OS provides APIs for hardware and software installed in the box.
For your question, an API is a method (code instructions) to connect your application to the features of another system. Allowing your application to use thay system's features as provided via the API.
Could someone explain to me in case of Google maps or Youtube which is
the API and which is the software application?
In the case of Youtube... Let's say you are making some Android video player app that you also want to be able to playback Youtube videos within that app. The software application is your own Android player code and to access the Youtube data you would use Youtube's Android API.
An example of using the API is this module : YouTubePlayer which as you can see provide API commands like loadVideo(String videoId, int timeMillis). Where videoId is the Youtube ID and timeMillis is the desired start time within the video).
When we write for example http://maps.google.co.uk/ how do we call the
API?
That's not how you would call the API. You must first visit the documentation of the API to see how it's expected to call features within your own app.
Google Maps : https://developers.google.com/maps/documentation/
Let's assume now you're coding a Javascript app, you can see the commands here as a startng point. There is also an example page showing code & result.
Simple terms:
API = the waiter
Application Software = the chef
You order from the waiter. The waiter brings it to the chef. The chef prepares the food. The waiter then brings you your food. Then you figure out what to do with the food; eat it, take it home, throw it on the floor, let your dog eat it, give it the homeless, etc...
A website, app, etc... would send an API request (your order with the waiter) to Google Maps (the chef). If your API request is valid, Google Maps will send back an response (your cooked food with the waiter). Then the website or app takes the returned data and displays it in their custom way to you.
In the case of Google Maps, apps like Yelp and others use Google Maps' API to request specific data; routes, addresses, etc… and then they display it on their app.
To make an API request/call you have access to use the API, format it correctly, and figure out what to do when Google sends a response back : https://developers.google.com/maps/documentation/
API is a set of functions and procedures that allow the creation of applications which access the features or data of an operating system, application, or other service.
An API is like building block for your application. Multiple API's can exchange data without knowing the other's implementation. In a good design pattern , we should design API's for different independent tasks and then merge them.
Google Maps API
This is the google maps API which a developer can use to develop his own piece of software.
Whenever we use any software and it's different features, we might be using their API's without generally knowing of them.
A software application is always visible to us, but an API is visible only if the developer wants to expose it for community use.
EDIT
Using Google maps API
This link has the documentation and examples on how to use the google maps API using javascript.
Hope it helps!
When you use software, web applications included, you are in most cases using a wrapped API. Software developers took the time to take a raw back end API which executes commands on the system, and made these endpoints easy to use for a specific user in an intended universe of discourse, or domain. End users do not have direct access to everything the API has to offer all at once, so it is not "available" in the same sense that it is available to the developers, but it is available in another sense because they are using the API to execute commands on the system by virtue of the Application that was Programmed with that Interface existing and working.
The Google Maps API is used to integrate the power of Google Maps into almost any application. It provides facilities for customization and much more. When you use the Google Maps webapp, it is, to my knowledge, built using many components of the Google Maps API, as are the Google Maps apps for any other platform, such as Android. Does this mean you as a user are using the API? Only through the application; the application talks to the API for you.
“An application programming interface (API) is a set of routines, protocols, and tools for building software applications. An API expresses a software component in terms of its operations, inputs, outputs, and underlying types. An API defines functionalities that are independent of their respective implementations, which allows definitions and implementations to vary without compromising each other. A good API makes it easier to develop a program by providing all the building blocks.
APIs often come in the form of a library that includes specifications for routines, data structures, object classes, and variables. In other cases, notably SOAP and REST services, an API is simply a specification of remote calls exposed to the API consumers.
An API specification can take many forms, including an International Standard, such as POSIX, vendor documentation, such as the Microsoft Windows API, or the libraries of a programming language, e.g., the Standard Template Library in C++ or the Java APIs.
An API differs from an application binary interface (ABI) in that an API is source code-based while an ABI is a binary interface. For instance POSIX is an API, while the Linux Standard Base provides an ABI”.
To speak plainly, an API is the messenger that runs and delivers your request to the provider you’re requesting it from, and then delivers the response back to you.
To give you a familiar example, think of an API as a waiter in a restaurant.
Imagine you’re sitting at the table with a menu of choices to order from, and the kitchen is the provider who will fulfill your order.
What’s missing is the critical link to communicate your order to the kitchen and deliver your food back to your table.
That’s where the waiter (or API) comes in. ”AHEM”
The waiter takes your order, delivers it to the kitchen, and then delivers the food (or response) back to you. (Hopefully without letting your order crash if designed correctly)
Now that we’ve whetted your appetite, let’s apply this to a real API example. In keeping with our theme, let’s book a flight to a culinary capital – Paris.
You’re probably familiar with the process of searching for airline flights online. Just like at a restaurant, you have a menu of options to choose from ( a dropdown menu in this case). You choose a departure city and date, a return city and date, cabin class, and other variables (like meal or seating, baggage or pet requests)
In order to book your flight, you interact with the airline’s website to access the airline’s database to see if any seats are available on those dates, and what the cost might be based on certain variables.
But, what if you are not using the airline’s website, which has direct access to the information? What if you are using online travel service that aggregates information from many different airlines? Just like a human interacts with the airline’s website to get that information, an application interacts with the airline’s API.
The API is the interface that, like your helpful waiter, runs and and delivers the data from that online travel service to the airline’s systems over the Internet.
It also then takes the airline’s response to your request and delivers right back to the online travel service .
And through each step of the process it facilitates that interaction between the travel service and the airline’s systems - from seat selection to payment and booking.
So now you can see that it’s APIs that make it possible for us all to use travel sites. They interface with with airlines’ APIs to gather information in order to present options back to us
The same goes for all interactions between applications, data and devices - they all have API’s that allow computers to operate them, and that's what ultimately creates connectivity.
API’s provide a standard way of accessing any application, data or device whether it is shopping from your phone, or accessing cloud applications at work.
So, whenever you think of an API, just think of it as your waiter running back and forth between applications, databases and devices to deliver data and create the connectivity that puts the world at our fingertips. And whenever you think of creating an API,
--MuleSoft
Long time ago, I took and passed the Google Analytics IQ certification test. At the time, I don't believe there were such things as Core Reporting API, Management API, and Metadata API (and probably some other Google Analytics related API's that I don't know about). Now that I am going through the Google Analytics IQ certification training course again (provided by Google, presented by Justin Curtoni?? I believe that's his name), I found that they now have Core Reporting API, Management API, and Metadata API.
I am a computer programmer by trade; so, I have no problem with programming using these API's. However, what I don't understand is, what do these API's buy me that the Google Analytics UI cannot offer? There is no reason to write a program that utilizes these API's simply because I can do it. To me, the existing Google Analytics UI has a lot of tools, reports, and other features that quite extensive. I am hoping that some of you can help me see something that I am probably missing.
The APIs are primarily for programmatic access. For example, if you need to create 1000 accounts all with the same property/view structure and then maybe add a few view filters to each of those accounts, you'll probably want to use the Management API. Doing that by hand would be a nightmare.
The same thing is true for the reporting API. Maybe you want to set up task that runs every monday morning and reports on the previous weeks data. And maybe you want to display that data on an internal dashboard for your company using some fancy charting library. You'd have to use the API to get the data.
Dashboards (executive summaries; managers often want nice visualizations instead of boring drill-downs)
Custom reports for user groups that do not have a Google Account or are not supposed to have access to full reports (e.g. Affiliates)
advanced filtering and aggregation (GA report cannot do everything)
You can combine analytics data with external data (e.g. you are not allowed to store personally identifiable information within GA; but you might store a custom key that allows you to link analytics data to customer data from you CRM or fulfillment system)
Machine-to-machine communication; I once did tracking for an airline that needed trend data on what people where searching for and what they where actually booking; that data was used to allocate/withdraw resources from busy/lame flights, and part of this was done by hooking up GA to their backend system
Take a look at the GA Partner Page. I would say the primary reason is to "liberate" GA Data from outside of GA itself. As Eike mentions, you can create dashboards and combine this data with other sources for a complete "View" of your online presence.
HI I guess there is no definite answer. Here are some things you can do with the APIs:
Automating AdWords CRO based on keyword ad and campaign performance.
Scoring leads based on Analytics data (Engagement with different items) and external data from a CRM.
Collecting unsampled data using multiple daily queries
Filtering using several dimension.
Tracking conversions for periods longer than supported by AdWords.
Looking at a funnel via segments
Analyzing funnels with non-linear structures
Create more robust alerts
Export data to BigQuery and analyse it together with data from other systems.
Create Machine learning apps for behavioural customizing your site.
Create a dashboard with data from multiple views
Use product recommendation to implements "better together" in an online store.
Automate creation of accounts and properties + their integration in a Hosting provider's console.
Cheers!!