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.
Related
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.
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()
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.
I need to pull a piece of data from a custom field in the regarded account or case and pull it into a field in a phone call form. (its just to identify which account group the call took place from)
I am not sure of the javascript code to pull from the regarded account or case.
Can someone point me in the right direction.
Thanks in advance.
If you want to do this in javascript, you'll have to access the organization endpoint and retrieve the account/case record. The main form contains the regarding lookup field, which will have the GUID, display name, and entity name of the record. The CRM 2011 SDK has some sample code for retrieving records in Javascript, and they even have a library you could use that does all the hard work for you.
Entity Application has a look up to Contact. Now, Entity Application Document has a look up to Application. In my Application Document form, I want to display the Contact who is associated with the Application Document. I do not want to be creating a look up to Contact as it is just bad database design.
How can I show the related contact in the Application Document form. It is after all a look up - alright, a two level look up right? I can go from the Application Document to the Application to which it is related and from there to the Contact.
My suggested solution would be to have a read only text field in the Application Document entity. Populate it with Contact (Primary Field) onloadform with a JavaScript.
I'd resolve it as a call to the DB, fetching the linked entity and then fetch it's linked entity. JavaScript seems to be the wises choice in this case.
However, you mention that you find this solution bad, so I might be missing a requirement.