What is the ideal scenario to use platformwebservices and ycommercewebservices, and what is the difference between the two.
Platformwebservices
provide secure CRUD access to all models in the service layer over a well understood and widely adopted protocol.
A secured RESTful access to all Hybris models, when you create or update an item the platform web services will generate / update the API for you.It's accessible from '/ws410'. You do not need to change anything within this extension.
Ycommercewebservices
exposes part of the Commerce Facades as REST-based web services, including calls for product search and product details. The focus is to provide a working example of how a REST-based API can be exposed.
First it's a template, as it starts with 'Y' so to create your own you need to run 'ant extgen'. It will provide you RESTful access to few out of the box Facades. Up to you to add more Facades or update the existing one.
for OCC implementations use CommerceWebservices. PlatformWebservices are for doing basic CRUD operations and it completely bypasses the business logic .
So if you want to leverage any hybris provided business logic and don't want to write your own logic for example cart management CommerceWebservices is the recommended way.
Related
I want to publish my API, but I want to limit so users can only execute in sandbox environment (I want to limit production to specific user/customers with specific agreement).
This is a basic functionality in other API managers, but I don't find how to do in WSO2.
I have found this article in Medium, and also noticed that when I create an aplication, a couple of new roles are created (Application/user_application_SANDBOX and Application/user_application_PRODUCTION), but I don't find how to use them.
Deep dive in doc doesn't helped me.
Option 1:
You can use application registration workflow to control key generation for production and sandbox, by sending it through an approval process.
If you want to automate it based on a property or something, you can write a custom workflow extension.
However, this is applied to applications but not to APIs. That means if you allow generating prod keys for an application, all APIs, that the application has subscribed to, are accessible with prod keys.
Option2:
If you want to do this in API level, you can write a custom mediation sequence. Within the custom sequence, you can read the key type (i.e. production or sandbox), subscriber, enduser (if required) etc. and decide whether you want to allow the request or not.
We have a custom web service for Acumatica, that we would like to integrate into our extension library. This is a service that accepts data to post into Acumatica (multiple DACs used).
However, I cannot find any information on the proper way to do that.
We use Web API (Api Controller) and route based endpoints, and it is likely that some registration needs to take place when the extension library is loaded.
Any pointers to how this should be done?
b
I'm using Azure Custom Decision Service (https://learn.microsoft.com/en-us/azure/cognitive-services/custom-decision-service/custom-decision-service-overview) and have a few API questions.
From the documentation, I'm seeing that there is a Reward API for user clicking on the first recommended article. But is there other click events? Is the service also "learn" when user click on an article that isn't in the recommended list?
I couldn’t find where we send user info, how does Custom Decision Service helps with article “personalization”? Is it based on a cookie?
At the moment, we're only learning from a click on the top slot or first recommended article. We are considering enhancing the Decision Service to support learning from clicks on multiple slots but this is not yet in the service.
We automatically generate user features, today we use geo location and device type. We do use cookies but we're not learning from those yet.
In a Loopback application, there's mention of a built-in Application model.
This page says "contains metadata for a client application that
has its own identity and associated configuration with the LoopBack
server."
When clicking through the referenced page it further elaborates with this:
Application model
Use the Application model to manage client applications and organize
their users.
The default model definition file is common/models/application.json in
the LoopBack repository.
The first link in that paragraph I think is incorrect as it refer to the Express application wrapper, rather than an instance of the model.
The second link details the attributes of the model. There's mentions of things like ownership, realms (which is mentioned in the context of Users), and various other settings.
The Application model is mentioned in a few places in the documentation but it doesn't really explain how to use it.
How would you access the Application model in an app?
Where are all the attributes defined in your app?
Can you have more than one Application instances, and why?
Hope this isn't taken as a subjective topic, I'm really just after better documentation on the topic.
The Application model in LoopBack is meant to act similarly to the User model, but instead of individual users using the API, apps can also gain access to the API. An example would be if you had a payment API. You might want to grant access to users so they can transfer money to each other, but you might also want to grant access to a web app (online store) or provide a payment service to mobile apps.
I suggest going into server/model-config.json and adding the following:
"application": {
"dataSource": "db",
"public": true
}
You can then open up the component-explorer and play around with API endpoints for the application model. Here are the API docs
(I also suggest you open up an issue on loopback requesting better documentation.)
What are the basic functionality which it provides?
Specifically for the person who has never used asp.net built in stuff.
The MSDN tutorial is confusing me a lot. Claims, OWIN,etc are going above my head.
What I can make out of all this is - The Identity framework helps me to manage my application plus social logins. It handles my cookie,etc.
What if I have just one role in my application - just the plain user?
Should I go for the Identity then or I should implement my own custom thing?
Any help is appreciated.
If you are starting from scratch, build a sample MVC project with individual membership option, which will create the following components for you:
Login module that creates and manages authentication cookies
Simple database to store basic user data (credentials, name)
EF code to interact with the database
This will most likely meet your use case for a user without roles and attributes.
OWIN really has nothing to do with authentication, it is a new spec for building web apps. The login module happens to be implemented according to this spec and it sounds cool, so Microsoft likes to throw this term around a lot.
If you are not planning to have authorization logic in the app, then you don't need to worry about Claims. Claims is another term for user attributes (login, name, roles, permissions). The Claims collection will be populated by the framework, but you most likely won't use it. If you need just the user id/name, the old ASP.NET interfaces are still there to get this data.
As far as implementing your own, I've seen people here ditching the database and EF code, especially if they already have an existing user store. You just need to implement a credential verification logic against your store. You don't want to build your own cookie management, though. Use the login module provided by Microsoft or well established third party systems (SiteMinder, Tivoli, etc.)
Looks at this open source project for a good alternative to ASP.NET Identity.
This is a very well put together tutorial that explains many of these concepts, you can get a free trial to the site to see it.