I'm migrating a project using hybris 5.4 to 2105.
In the project, there is a custom OMS extension using omsOrders, omsclients and omsats and in version 2105 these extensions don't even exist.
Any alternative to solve the extension errors or will I have to practically redo the business logic?
Because, in this custom OMS extension, each order is sent on an endpoint and according to the endpoint's response, the order is updated according to the business rules
Related
We have an extension developed for internal use that uses WebRequest API. The extension is installed using "ExtensionInstallForcelist." Based on various documentation, it seems like we would be able to continue to use WebRequest API but there are parts that are still unclear.
The timeline on https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/ states that "January 2024 - Manifest V2 enterprise policy expires."
Does this mean that starting January 2024, Chrome will stop running Manifest V2 extensions, even the one that is installed using "ExtensionInstallForcelist"?
This article says "public" extension is one that is published to the webstore. Does that definition also apply to "unlisted" extensions? Right now, we perform initial install from our server using "ExtensionInstallForcelist" but update from the webstore having the extension unlisted.
The reason why we update from webstore was because updates used to be only allowed from the webstore. (We may have missed something) But it looks like starting from version 89, there was an option introduced that would allow updates from outside of the webstore. The option is "override_update_url" in ExtensionSettings. Does anyone have experience with this option?
I have updated my storefront Spartacus app from 1.4 to 3.1.
As per Spartacus technical changes we need to change backend.occ.prefix from /rest/v2/ to /occ/v2/.
After changing this, backend service call urls are getting changed.
Before change I had below URL call,
https://localhost:4200/rest/v2/basesites?active=true&showExternalSites=true&fields=FULL.
It returns valid data.
After backend.occ.prefix change to /occ/v2/ am getting below URL call,
https://localhost:4200//occ/v2/basesites?fields=baseSites(uid,defaultLanguage(isocode),urlEncodingAttributes,urlPatterns,stores(currencies(isocode),defaultCurrency(isocode),languages(isocode),defaultLanguage(isocode)))&lang=en&curr=USD
It returns 404 error.
Do we need to change any configuration in hybris setup or need any other changes from Spartacus storefront.
I have hybris version 1905.19
Please help me to get this fixed.
Thanks.
You need to set backend.occ.prefix as /rest/v2/. occ extension comming with version 2005. On the other hand I think you will get a lot of error with 1905 with spartacus, because a lot of services comming with occ extension. You need to develop all of them on 1905. You need to think about upgrading 2005 or later.
We understand that these are the options available from SDK to connect to ODATA Service
Option 1 - If the ODATA Service is not supported implicitly by SDK, Use com.sap.cloud.sdk.odatav2.connectivity.1.ODataCreateRequestBuilder
Option 2 - If the ODATA Service is not supported implicitly by SDK, Use VDM generation approach.
Call the services using generated Java classes
Option 3 - If the ODATA Service is supported implicitly by SDK, Use the already available class
e.g. 2> com.sap.cloud.sdk.s4hana.datamodel.odata.services.OutboundDeliveryService
Now we have have some questions and need expert guidance here
Question 1 - We have a use case where we need to call oDATA Services from a third party system
which option we should go for Option 1 or Option 2 ?
Question 2 - What are these cases where Option 1 is preferred over Option 2?
Question 3 - We also have a use case where we need to call S4HANA ODATA service related to OutboundDelivery. Service is supported by SDK by class com.sap.cloud.sdk.s4hana.datamodel.odata.services.OutboundDeliveryService
But there is one new field is getting added to the service during current release. We need to update this field
In this case which option is suggested?
Question 4 - How frequently new fields on existing S4HANA odata services are included in SDK?
I hope I can enlighten you a little here:
Regarding 1: Personally, I'd still recommend going with option 2 and generate client code using our generator. This will give you the same convenience that you know from the S/4 services for any other OData service. If, for some reason, the generated code does not work against your third party service, you can still use option 1 as a fallback.
Generally speaking, our generator should work for any OData v2 service, not just SAP services.
Regarding 2: As already mentioned, the generic OData client always works well as a fallback, if the generated client does not work whatever reason.
The other case I can think of (and this should be rather rare), is that you yourself are exposing one service that retrieves it data from several downstream OData services. In this case, the generic client might give you some advantages over the generated one.
Apart from that, I'm not aware of any use cases where I'd personally go with the generic client over the generated one.
Regarding 3 and 4: The VDM packages that we ship as part of the SAP Cloud SDK contain the OData client code for the current release of SAP S/4HANA Cloud. So if the services in SAP S/4HANA Cloud are updated, our packages will reflect that update. If you're working with SAP S/4HANA On-Premise, there's generally a good chance that the service is compatible with the Cloud version. If not, you can still use our generator to generate client code with the metadata of the respective On-Premise service.
It's described as a non-required field, but it's an enum (without any other listed options) and the description is vague: Used by the Application Insights system to determine what kind of flow this component was created by. This is to be set to 'Bluefield' when creating/updating a component via the REST API. - Bluefield.
My rule of thumb is don't include anything extra (KISS) that doesn't break my application, but if there's some benefit I can get out of it, I'd like to know. Thanks!
Reference: https://learn.microsoft.com/en-us/azure/templates/Microsoft.insights/components?toc=%2Fen-us%2Fazure%2Fazure-resource-manager%2Ftoc.json&bc=%2Fen-us%2Fazure%2Fbread%2Ftoc.json
Flow_Type and Request_Source Do not have any effect in the current version, and they might be deprecated in future versions of App Insights API
I want to use the Web Platform Installer to perform installations and manage dependencies, but because we store version information in a database, the options for discovery that are supported by the WPI won't work for us.
Based on what I've learned so far setting up a custom feed, I don't even know how you would inject any sort of custom logic into the application, but I thought I'd better throw a question out here before I give up.
Is it possible to add custom logic for how the Web Platform Installer discovers which services have been installed?
Thanks!
As far as I've been able to tell, this is not possible. We ended up coming up with a custom solution to fit our needs.
For those interested, chocolatey (http://nuget.org/List/Packages/chocolatey) is another great utility for custom installations.