I have a new feature called wishlist. This feature has separate OCC. how (and where) would you recommend I include the new OCC calls using your framework?
We are currently developing this feature, so we would recommend to wait for it, if you can.
If you can't, you need APIs on the back-end, and you can use our connector / adapter patter to talk to a different system or custom APIs: https://sap.github.io/cloud-commerce-spartacus-storefront-docs/connecting-to-other-systems/#page-title
Related
We have exposed some new API’s from SAP Commerce and need to get/post data in some of the components or services.
Are there any pre-defined mechanisms to leverage new API integrations, or should we simply use HttpClient from Angular?
We are expecting that there should be a way to get data from new API’s like we have for OOTB API’s such as “StoreFinderService” which helps us to get data for store and there are some other services as well.
Spartacus is using NgRx to handle all API’s and then these services supply data from stores. Similarly, there must be a way to get data for new API’s created as per business requirements.
Spartacus uses the Angular HttpClient under the hood, it's the recommended service to interact with http. However, using HttpClient directly from a component is generally considered a bad practice. You'd better separate concerns, and delegate interacting with the backend to a service.
Spartacus offers an extensive architecture to handle backend APIs, you can read more about it at https://sap.github.io/spartacus-docs/connecting-to-other-systems. You could follow this architecture, but for a project it's overcomplicated. The architecture really targets extension points, which is fair for a product, but most often not for a project.
https://github.com/SAP/spartacus-bootcamp/tree/master/src/app/features/state shows you some examples of introducing a custom state to the Spartacus state.
For projects introducing new features, I would either create and maintain state in a service, or introduce a custom state in ngrx. For the later, you can evaluate https://github.com/SAP/spartacus-bootcamp/tree/master/src/app/features/state that shows how to add new state into Spartacus, or read up on ngrx resources.
I need to use multiple APIs from multiple sources in my new website. They are all similar in functionality but with some differences in format. Then I need to build some type of proxy to make them all the same before use.
Can I use an API Management solution like WSO2 to integrate all these APIs and standardize them as a single API?
Is there another solution for this?
Thanks
You are actually looking for an integration solution. Therefore, what suits best is the WSO2 Enterprise Integrator. You can write a couple of Synapse code to combine a set of APIs and expose them as one.
Now, if you need to enforce policies such as authentication, authorization, rate-limiting etc. (i.e. if you need to expose this API as a managed API), then only you need APIM in front of it.
Kloudless provides an abstraction layer via a single unified API to connect to several third-party APIs without having to implement code for each of them. In that way, it functions as a proxy for all those third-party APIs and abstracts out data models, authentication, error-handling and rate-limiting, and more. (I'm a co-founder)
Use Wso2 Enterprise Integrator where You can create API and Apply the various integration patterns to achieve your requirement. Then if you need you can publish the same in API management.
ESB requirement:
You can use either a management console for creating API's or an eclipse designer extension from wso2. For creating API's XML knowledge is enough otherwise it also provides drag and drop feature.You don't require JAVA knowledge as the inbuilt mediators which are shipped with Wso2 ESB is enough. But if you have knowledge of java then you can create custom meditaors(mediators are used for creating busniess logic) incase of some special needs. If you don't know JAVA then you can use Javascript, Ruby, Groovy inside script mediator. I prefer for smaller transformation I will use Script mediator if you have larger message size then you can go with class mediator that's where we'll use JAVA. This is all the requirement you need for ESB.
Technologies required for ESB: XML, XPATH, JsonPath, XSLT, Xquery , scripting knowledge(Javascript, Ruby, Groovy)etc.
If you are beginner then please refer this tutorial https://docs.wso2.com/display/EI640/Integration+Tutorials
For API management programming knowledge not required.
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!
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.
I like to document my API (REST with JSON) which is written in PHP with the Symfony2 Project. This means I would like to write a public API, which I can give out to my clients, without showing them my internal functions etc.
What is the best practice to write Documentation in the public functions (Controllers, etc...). I'm currently using YAML for routing, which seems to be incompatible with the Annotation Based PHPDoc.
Thank you in advance!
You should then use NelmioApiDocBundle which was designed specifically for the need of documenting Restful Symfony2 API(s).
Find the bundle's documentation here.
It provides an ApiDoc() Annotation for Controllers,
The ApiDoc() Annotation.
And it also allows you to browse the whole documentation through an interfactive web interface,
On-The-Fly Documentation - Web Interface.