Is it possible to make a call from advanced workflow to the Archer API? I'd like to avoid making a custom object and didn't know if I could somehow otherwise initiate a call.
No, you can't call Archer API from Advanced Workflow functionality.
Any data related manipulation can be done with a data feed. And where "Archer to Archer" data feed can't deliver "SQL" type data feed will. SQL data feeds targeting Archer Instance database can do magic if you are willing to document them and test them with every Archer upgrade.
I had to use Archer API only in very complex integration cases. In these cases API code was running on the application server as a service. I think that invoking API calls via JavaScript from end user's browser can be considered a bad practice.
Related
I'm trying to understand how Swagger UI works and what kind of scenario it suits for.
Per my understanding, it's not a sandbox when integrating with Swagger UI. That means Swagger UI manipulates real data. Is that correct?
So usually I have to build a dedicated test environment for Swagger UI, right? Sounds not right to me.
Even there is a test environment for Swagger UI, since it's open to lots of people. Does that mean the dummy data posted by someone will be saved forever and visible to others?
I was expecting Swagger UI behaves like a sandbox which only saves and manipulate the data for the current session. Once the user closes the session then re-open it, it should be brand-new.
I would like to know the typical scenario in which Swagger UI is used.
It's in the name, isn't it? It generates a UI for your API.
It does not spin up a demo environment for your API with the accompanying back-end, including a test database that contains dummy data and/or is periodically wiped.
If you want the latter, you'd have to build that your own.
Does that mean the dummy data posted by someone will be saved forever and visible to others?
Given that your API uses authentication, you will need authentication in order for Swagger UI to make calls. If you do not separate authenticated users' data, then that's a problem in your API, not a problem of Swagger.
Consider that Swagger UI presents you with a visual way to call your API. Anything you can do with Swagger, you can do with any REST/HTTP client, and so can your potential consumers.
Has anyone managed to create a custom integration between Zapier and Xero by using the 'Webhooks by Zapier' option and a private connection on the Xero side?
At the moment Xero uses Oauth-1a to create sessions and I can't figure out how to even approach this.
I know Zapier has a normal integration with Xero, however I am interested in doing something which isn't available in their integration (create manual journals) and for this I need to figure out how to do the connection manually.
Thanks
Have you taken a look at Xero's Private Application Auth documentation? The private key you create becomes your Consumer Key for API calls. Unfortunately, from there, you do need to do a little coding to support Oauth1 in Zapier.
You have two options:
You could use a serverless function platform like Google Cloud Funtions or AWS Lambda to host your code and use one of Xero's SDKs (like pyxero). You then use a webhook step in Zapier to call the function.
This option is the most robust since and avoids Zapier code limits
You can use a Zapier code step to place the call. In order to do this, you will need to create your own Oauth1 header for your call. You can look at the post HERE by Eliot Muir.
You'll see on lines 32-34 of his example output the headers that need to be included. He has done the hard work of crafting them so you would just need to pull the relevant code and strategy.
This is the most streamlined solution, but you do have to deal with Zapier's lack of 3rd-party packages and a 10-second timeout
I would like to create my own web chatbot and i like to integrate my app with wit.ai for natural language classification.I need to know how to integrate wit.ai service(through api call) with my application(any language in backend).i am using C# in front end.I have gone through the integration part Which posted in wit.ai website.But i don't know how to connect it .Could anyone send me a integration details little briefly
I think the short answer is its similar to how you would call any other APIs from your application server components. Wit exposes multiple APIs like message, speech and converse which you can call by passing the Authorization token and other payloads and make use of the API response in your application.
You can use message API if you are only interested in extracting
intent and other atributes of the sententense
Use speech for building voice based application and
Converse if you want to build a little more smarter app. Currently you can only pass text for converse APIs.Hoping they will introduce voice option for this soon.
Now to make things simpler, they have also provided SDKs in various languages like node-wit, pywit etc. So if you want to build your server side logic using on nodejs or python you can use these SDKs. The advantage is that you dont have to manage raw APIs calls and instead it is all managed by SDK. Also, other big advantage is that you can make use of runActions method which encapsulates converse API and make things simpler. If you want to build in nodejs then the messenger example is a good starting point. You can borrow all this logic/concept in your app and replace FB related calls etc with your custom bot. For Python you can look at the below link
https://github.com/wit-ai/pywit/pull/55
Also, you can explore the options like using other frameworks like botkit if you plan to integrate wit with other chatbots like FB messenger or slackbot as these frameworks provide more flexibility and ability to easily switch to different chatbots in future. But they don't seem to properly support the converse API of wit.
You are specifically looking for integration details. Since you are using c# for frontend app, natuarally the best option would be to use c# for backend as well. In which case you will be left with directly calling wit APIs from your backend as I think there are no SDKs in c#. If you want to make use of SDK in node or python etc then you will have to build a rest based backend (for example) which can be invoked from your c# application. I am currently working on a nodejs app and integrating it with wit using node-wit. I can share some code once its ready but i dont know when I will be able to finish it. For bootstrapping my application I have used this node application. If you have some understanding of node then you can look at the /server/controllers logic. Similar to this application I have built a witController which uses runAction to interact with wit and I am calling this from front-end when user submits a message to your bot. The biggest challenge in runAction is to figure-out a way to send back the wit response to your front-end and get follow up response from user. Wit sends the response in Send method as you can see in the node-wit's messanger example.
Hope this helps!
We're required to use the API of an external partner. The API is in a good shape and we got access to a sandbox environment we can use for automatic testing.
We already test every single call of the external API using unit tests but are unsure regarding best practices for integration tests when it comes to complex operations on the side of the external partner.
Example: Every user of our service also got a user object at our external partner. When performing external API call X on this user object, we expect object Y to appear inside collection Z of this user (which we have to query using a different call).
What are best practices for testing cases like this?
Mock the external API as much as possible and rely on the unit tests to do their job? Advantages: Tests run fast and independent from an internet connection. Disadvantages: Mistakes is in our mocks could lead to false positives.
Integrate the external API sandbox and run every integration test against it. Advantages: Close to real life API interactions. Disadvantages: Tests can only be run with an open internet connection and take more time.
Use a hybrid of mocked and sandbox data, set a boolean to switch between the internal (=mocked) and external (=sandbox) environment when required. Advantages: Reliable tests. Disadvantages: Could be a pain to set up.
Other best practices?
Thanks!
Related: How are integration tests written for interacting with external API? However, the answer "You don't. You have to actually trust that the actual API actually works." is not sufficient in our opinion.
[EDIT] We fear that integration testing only against our assumptions how the external API should work (even if they are based on unit tests) – and not against the actual API – will leave us with false positives. What we'd need is a test that verifies that our assumptions (mocks) are actually correct – not only in the context of unit tests but also in the context of complex operations with several steps.
Validation might be a good example: What if we mess up the integration code and send malformed data or data that does not make any sense in the context we send it in because we missed a step? Our mock API, which does not validate (or only in very limited range) would still return valid data instead of passing the error we would receive from the real API.
I believe there should be 2 level of verifications we need to do when we interface with an external API:
API verification: verify that the API works according to its specs and/or our understanding
App functionality verification: verify that our business logic works according to the expectation to the API that passes API verification
In our case, we use a mock API together with real and mock API verification.
Mock API allows us to isolate any runtime errors/exceptions to app functionality only, so we don't blame any external party for issues
The same API verification is executed against both real and mock APIs, to make sure that the real one works the way we expect, as well as the mock one should mimic the real one correctly
If along the way, external API changes, API verification may turn red, triggering changes in mock API. Changes in mock API may make app verification turn red, triggering changes in app implementation. This way you never miss any gap between external API and app implementation (ideally).
Another extra benefit of having a mock API + API verification is that your developers can use it as a documentation/specification of how the API is supposed to work.
I am new to web dev but I have managed to build my site using GWT and GAE. I use RequestFactory for client-server communications.
Now, someone wants to make mobile applications that use my backend.
I have found that RequestFactory works very well with Android. But I am somehow afraid it will not work with other "not-google" front ends (iOS for instance).
So my question is, can I make an API based on my RequestFactory backend (servlet) that can be used by any client? Any initial pointers as to how to implement it would be appreciated.
I guess technically it would be possible. However, if you want to create an api anyone can use, you probably want an api were you specify both how to communicate with the api and the content send/received by the api. With RequestFactory both the how and what is shielded by RequestFactory. So if someone wants to communicate with your api and can't use the RequestFactory code in the project, the how and what of RequestFactory must be reverse engineered, and could change anytime because it's not guaranteed. Not the most elegant way to go forward.
A better approach is define an open api were you specify the how and what. For example with
and apu based on REST (the how), communicating JSON data, and to specify the content format (the what). An example of such an api is the twitter api.
For your own project you could build on your api also, for example by using RestyGWT. Then you don't have to maintain both the code for the RequestFactory interface and REST interface. For other platforms there are probably several libraries available to make developing against a REST interface easy.