Update requests send no longer all fields to the SAP S/4HANA system - sap-cloud-sdk

Since the update to the Cloud SDK version 2.0.0 we now have problems to add fields to the request. It is mainly about the process step "Count Physical Inventory Document Item". Here the manually set properties for the items are not sent into the request.
These are the properties we actually set and send to S/4 System:
These are the properties that are embedded in the query:

Quick answer
Call the method includingFields(PhysInventoryDocItem.MATERIAL, ...) on the update fluent helper.
Longer explanation
Version 1.11.1 of the SAP S/4HANA Cloud SDK slightly changed the behavior of the Java Virtual Data Model (VDM) during update requests. The release notes state:
Update requests with the Java Virtual Data Model (VDM) no longer send all non-null fields to the SAP S/4HANA system, but only changed fields. You may need to adapt the logic in your code to explicitly change fields by using the setters of the entity classes, or use the includingFields method to manually specify fields to include.
So in your case, by default only fields will be sent that have a different value compared to the result returned by the get-by-key OData request, as typically expected for PATCH requests. For example, the value of the field material likely didn't change, because it was "MAT_KONSI_APP1" before.
Because there are cases that require some mandatory fields to be always sent, the SAP S/4HANA Cloud SDK allows you to control which fields to always send. Use the includingFields method on the update fluent helper of the VDM to specify the fields that shall be sent in any case, also if their value has not changed.
In your case, if you want to send the material and unit of entry fields, which may be mandatory properties, you need the following code:
service.updatePhysInventoryDocItem(itemToUpdate)
.includingFields(PhysInventoryDocItem.MATERIAL,
PhysInventoryDocItem.UNIT_OF_ENTRY)
.execute()

Related

How do I extend Strapi admin panel API controller to update a field

I have a requirement where I need to fetch duration of a video which comes from a third party API.
I have a videos collection type in Strapi, whenever a video is updated in Strapi admin panel, I want to fetch the duration from third party API and update the duration field.
I have written a controller in api>videos but it is not being called on admin panel update.
Please tell me how can I achieve this requirement.
Based on what you have described you may want to look at
Content-Type Hooks. According to this article (https://strapi.io/blog/understanding-the-different-types-categories-of-strapi-hooks).
These hooks allow us to extend Strapi's default Content-Type functionality by introducing custom code that will run whenever (before or after) a query is executed over a Content-Type.
In your case afterCreate method can be used to hit the third party API and then update field for video duration using Entity Service API as described here: https://docs.strapi.io/developer-docs/latest/developer-resources/database-apis-reference/entity-service/crud.html#update

Is there an equivalent to the default source, when using SetupIntent & PaymentIntent?

With the Sources API, every customer had a default_source, but when using SetupIntent (in order to be compliant with the PSD2/SCA directive), there doesn't seem to be any direct equivalent.
So my question is, how this can be properly represented API-side (without using metadata)?
The payment_methods listing seems to have a property called preferred for the card (which seems to be what I am looking for), but so far I have not found out, how to get/set this property.
There is no direct equivalent to the default_source for Payment Methods and the newer APIs like Setup Intents and Payment Intents. The closest thing is invoice_settings.default_payment_method, but it only applies to Invoices.
To answer your question directly, you have three choices:
Set and use the value of invoice_settings.default_payment_method, specifying the Payment Method stored there explicitly for each Setup and Payment Intent
Specify the default Payment Method in metadata as you suggested
Stored the default on your end in your own database
Regarding the preferred property, if you're referring to card.networks.preferred that is the preferred card network of the card in question and is not relevant to your question.
If you use Webhooks, you can listen for payment_method.attached or setup_intent.succeeded events and set it as default when they are fired.
For more info:
https://stripe.com/docs/api/events/types
Payment method object can be set to update Customer invoice_settings property with a default payment method.
https://stripe.com/docs/api/customers/update#update_customer-invoice_settings

Maximo- Update work order using RESTApi by passing wonum and siteid instead of workorderid

We are currently on Maximo 7.6.1 and have started to use Restful APIs and was wondering if there is a way to update a work order using RESTApi by passing wonum and siteid instead of workorderid.
We would like to avoid one additional GET call for our middleware to retrieve the workorderid and then use it in the PUT request.
Using this URL (OS as well) tries to insert a record even though the HTTP method is PUT.
/maxrest/rest/mbo/WORKORDER?_action=AddChange&siteid=XXX&wonum=7065644&description=Testing
Any pointers will be helpful.
Thanks
The IBM documentation appears to suggest you can only update existing records with the unique ID:
Use the PUT method to update or insert a resource. An update request
must provide the unique ID of the resource. To update an object
structure resource, the ID of the main object is required.
https://www.ibm.com/support/knowledgecenter/en/SSLKT6_7.6.0/com.ibm.mif.doc/gp_intfrmwk/rest_api/r_rest_put_method.html
The response received using the url you provided appears to bear this out in as far as it indicates the work order cannot be created as it already exists:
Error 400: BMXAA4129E - The record for Site=BEDFORD, Work Order=1234
already exists. Ensure that the key value for the given record is
unique.
Reviewing the information at the following url I wasn't able to determine a method to perform the update without the unique ID:
https://www.ibm.com/developerworks/community/wikis/form/anonymous/api/wiki/02db2a84-fc66-4667-b760-54e495526ec1/page/87348f89-b8b4-4c4a-94bd-ecbe1e4e8857/attachment/0a884bde-d17e-471b-b046-7f8feddfd267/media/MaximoNextGenRESTAPI%20%281%29.pdf
In addition the Maximo RESTful API Swagger documentation indicates a POST to /os/mxwo is used to "Create a new resource":
/maximo/oas3/api.html?includeactions=1#/Work_Order_Definition_(MXWO)/post_os_mxwo
Whilst a POST to /os/mxwo/{id} is used to "Update WORKORDER Object":
/maximo/oas3/api.html?includeactions=1#/Work_Order_Definition_(MXWO)/post_os_mxwo__id_
I was however able to update an existing work order using the unique ID. This being the case I can only suggest one of the following:
If you're creating the work order first using the REST/OSLC API,
retrieve and store the unique ID from the response received when the
record is created.
If (1) above is not possible, perform a GET and use parameters in
the query to filter on wonum and siteid and only receive back the minimum of
fields (e.g. workorderid only).
If neither (1) or (2) are feasible investigate whether it's possible
to customise Maximo and create your own endpoint for the work order
object structure that takes wonum and siteid as parameters,
retrieves the mbo and performs the update.

Preventing EntityReference Checks from occuring when Creating/Updating an Entity in Dynamics CRM

When executing a CreateRequest using the MS CRM OrganizationService, it seems that any attribute of type 'EntityReference' is checked by the internal CRM pipeline using a SQL query against the respective base table looking for the key specified in the EntityReference object. It's basically a foreign key check substitute since CRM doesn't define actual foreign keys when you relate entities.
I'm trying to import some data into the system where I know the specified EntityReference's already exist since I just retrieved them (race conditions aside). Is there any way to bypass that internal check from happening when using the web services? I'd like to avoid having to do any direct SQL updates since it invalidates the auditbase and modifiedby information.
For example, inserting 100,000 entity instances which each have 5 entity reference attributes on them turns into 500,000 selects being issued, often for the same value. Please tell me there is a supported way around this?
No. The only supported way to create records inside Dynamics CRM is to use the API.

In CRM 2011, best way to send information from javascript to plugins

I have an HTML web resource on a CRM 2011 form that users will be entering data into. This data will be required by CRM create/update plugins if the user chooses to save the main form, but there is no functional requirement that the data needs to be saved to any field on the entity. I am considering a hidden dummy field that the data could be saved to, but am wondering if there is anything more elegant for persisting data from the client to server technologies. I've done some research on "sharedvariables" but haven't been able to determine if they might meet this need. Any example of setting a value using JavaScript and then retrieving it from a plugin would be valuable.
Edit: I just wanted to clarify the response that I received based on my testing. While CRM has "SharedVariables" available for both plugin and scripting use, any data saved in scripts will not be available to plugins. Data saved by one javascript function to "SharedVariables" will be available to other javascript functions registered for the same event, and data saved by a plugin is available to other plugins registered for the same event, but the data is not persisted from script to plugins or vise-versa. This leaves dummy fields as the only option for persisting data from javascript to plugins. As NickNow suggested, unless you need to persist the data to a database, deleting it on a pre-plugin would be a good idea. Thanks Nicknow!
The hidden/dummy field is the correct approach. SharedVariables don't exist, from the standpoint of a plugin, until the data is sent to the server.
The form save is just a UI to trigger the Create or Update event - from the platform's standpoint you are just sending an entity logical name, the record guid (for an update), and the fields/values. The plugin has no knowledge, and shouldn't require knowledge, of how the event was triggered.
What I do is create a field (such as `new_internalmessaging') as a text field (since I'll never persist the value to the database I just make it a 2000 character string). During a JavaScript OnSave event I grab whatever data I need into an object and create a JSON string which I then use to populate the field.
In my Pre-Create and Pre-Update plugins I retrieve the string and deserialize it to an object for use in my plugin (I can also place it into a SharedVariable at this point if I need it for a post plugin). At this point the plugin code should remove new_internalmessaging from the Target.
I do this to ensure the data in that field will never get persisted to CRM.

Resources