We have a custom OData Service. The service url is as below:
https://host:port/sap/opu/odata/sap/ZAPI_TRANSFERPRICE_CONDTYPE_SRV/$metadata
It can return all the price conditions by accessing the following URL:
https://host:port/sap/opu/odata/sap/ZAPI_TRANSFERPRICE_CONDTYPE_SRV/TransferPriceCondition
After the service classes are generated based on the metadata of this service. The getAll method is not generated.
I am not sure if something is required in the OData service.
SAP Cloud SDK Version is 3.7.0.
The getAll() method is disabled explicitly by setting sap:addressable="false" for the entity which is the case in the EDMX file you provided.
generally speaking when using the OData client generator, there will/should be a getAll method if your service does not explicitly forbid it. Can you share the metadata (edmx) file of that service so that we can reproduce the issue? Otherwise it's impossible to guess where the problem comes from.
Related
Currently we consume an S4HANA odata service in SCP using cloud sdk.
As recommended , We currently use VDM generation approach to generate VDM class.
Now we identified that the S4HANA ODATA service is extendable.
customers extend the service and adds new attributes to the entry.
We need to bring the extended attributes and process them through our business logic and place
them on SCP data base
Please share guideline for this. How to achieve this?
Since VDM generation is design time activity, we are not able to influence it at runtime as
ours is multitenant SCP application and S4HANA service is extended by some customers based on their individual requirements
Thanks
Apoorv
For the purpose of accessing extended attributes of S/4HANA OData service, you can make use of the accessors(getters and settors) on customFields available on the VdmEntity. Here is an example:
final List<BusinessPartner> businessPartnerList =
new DefaultBusinessPartnerService().getAllBusinessPartner().execute(destination);
final Set<String> customfieldNames = businessPartnerList.get(0).getCustomFieldNames();
for( BusinessPartner bp : businessPartnerList ) {
customfieldNames.forEach(s -> bp.getCustomField(s));
}
To set a value to a custom field, use for e.g:
businessPartnerList.get(0).setCustomField("ShoeSize",9);
You can read more about it in this tutorial.
I am trying to configure Azure API Management to use versioning and have it work with a Swagger / Open API document generated by Swashbuckle.
I have an API with 2 versions - 1.0 and 2.0. I have configured Swashbuckle to generate 2 seperate Swagger documents, one for each version. All good.
The versioning scheme is by path so consumers need to call the correct path (v1.0 or v2.0). Like so: https://someurl/v1.0/some/thing
I have defined both versions in Azure API Management and imported both documents.
The problem is that Azure API Management is adding the path to the base URL and then because the path that is defined in the Swashbuckle generated Open API document I'm ending up with https://someurl/v1.0/v1.0/some/thing in Azure API Management.
Below is a snippet of the generated Swagger / Open API...
And the API version settings in Azure API Management...
And the full URL in Azure API Management...
So, my questions is how can I generate a Swagger document, using Swashbuckle or any other tool in a way that I can support Azure API Management versioning using the path versioning scheme.
Thank you in advance!
Since OpenAPI specification itself does not allow you to define versioning scheme, it is impossible to infer user intention at APIM level. One may want to import API with /v1.0/ in path as a single API, someone else, like in your case, wants to have API + version set. APIM by default does not create/update version sets during API import, so the only way at the moment is to remove /v1.0 prefixes from OpenAPI spec before you import into APIM.
APIMs domain model allows one to control versioning scheme (path prefix, header name/value, query parameter name/value) at the level of API version set, so that you do not need to duplicate /v1.0 on every operation of your API. By nature of this if your API version set is configured to have path prefix of /v1.0 it will be appended to all API paths included into this version set. And that is what produces the doubling.
The following page describes how to get Operation Status with the REST API.
https://msdn.microsoft.com/en-us/library/azure/ee460783.aspx
Is it possible to get that Operation Status with the Microsoft Azure Management Libraries found at https://www.nuget.org/packages/Microsoft.WindowsAzure.Management.Libraries ?
Yes. Assuming you have an instance of the ManagementClient class, the method is GetOperationStatus. You pass in the RequestId of the request you want to get the status of.
Also, this method exists for specific resource clients too. For example, the WebSiteManagementClient class exposes this method.
According to my requirement in Liferay, I have created custom fields for roles and assigned it to a user. My goal is to call the JSONWS API and get these custom fields using NodeJS. I am not able to decide which API I should call.
This Url is having APIs: http://www.liferay.com/api/jsonws
I will appreciate for any kind of help.
Regards
AFAIK there is no options to access the expando value via exposed webserveices.
Probably what you can do is that, create a custom portlet, add a dummy entity in the service builder and in that expose a method for web service. In that method call the role API and expando API , and return the result you want.
Custom Fields are called "Expando" in the API and are modeled like virtual tables. The functionality that's exposed through webservices is ExpandoColumn and ExpandoValue. Probably the best way to figure out the parameters to give is to look at the matching database tables. Careful: You should only ever read the database and not be tempted to write to it.
I hate giving the advice to go to the database, but this is probably the quickest - at least for my explanation :)
Finally, I got a genuine solution without hitting database directly. JSONWS is having api :
/portal.expandovalue/get-data
Which helped me to get attributes assigned to a particular role.
The above API needs 5 parameters to be passed.
companyId: whaterver the companyId assigned for your liferay.
className: It depends upon, we created attribute for role or user
com.liferay.portal.model.Role or com.liferay.portal.model.User
tableName: CUSTOM_FIELDS
columnName: It is the same name you given for attribute
classPK: It is nothing but your role or user ID for which you have created Attribute.
In case you are getting "java.lang.NullPointerException" when using #user3771220 solution, try com.liferay.portal.kernel.model.User
Looking to create a completely external portal using only HTML5, JS, and CSS to show CRM 2011 data. It does not look like I can use REST or SOAP because they cannot authenticate externally. Does anyone know how I would do this?
Thanks!
To do this, your OrganizationData.svc service would need to be externally accessible, and it would need to function without authentication (or, your authentication would need to happen within your javascript - where the end user would be able to read your source code). Either way is not a wise idea, since all of your data would be visible to the world!
If you are only dealing with internal authenticated users, read up on the oDATA endpoint.
If you want to deal with external and/or unauthenticated users, you'll need to find another way to do this that does all of the data filtering & authorization control you need.
I think we normally achieve this using a intermediary integration service. You could have a service which has access to the Org service through conventional CRM authentication, and which provides a number of methods which can be called anonymously (or by custom security) by client code.
For example, a web page calls the 'int' service's 'getContact' method, passing an email address of the user. The 'int' service validates the user's email address and then retrieves the required data from CRM's org service, using credentials stored in a config file (a CRM user with sufficient permissions to serve the 'int' service's methods). The 'int' service then parses the data and returns it to the client code - which has no knowledge of CRM's existence - perhaps as JSON for usability.