In the documentation from FMI the HTTP-body example for creating records using FMS16 Data API (REST) looks like this
{"data":
{
"field_1": "value_1",
"field_2": "value_2",
"repetitionField(1)" : "fieldValue",
"Orders::OrderDate.0":"12/22/2015"
}
}
The last attribute Orders::OrderDate.0 sets a value to a field on a related record and since the record don´t already exist it will be created.
My question focus on the .0 suffix of the attribute name. It looks to me like the 0 indicates a serial/identifier for on which related record the value should be inserted. This leads me to wonder if it is possible to create more then one related record in the same request that creates the parent record.
The below body returns error that the record does not exist, but why can one related record be created but not two?
{"data":
{
"field_1": "value_1",
"field_2": "value_2",
"repetitionField(1)" : "fieldValue",
"Orders::OrderDate.0":"12/22/2015",
"Orders::OrderDate.1":"11/11/2011"
}
}
Any clue if the above code should work? Am I missing something?
I am fully aware that I can (should) post several requests aimed at the related tables layout to create the related records. I just wish to know, since the .0 notation is in the documentation, does it should have a valid function?
Found this under the notes section in the doc you linked to:
"Only one related record can be created per create record call."
So there you have it. Looks like it behaves similarly to record creation from a portal, where you also can only create one related record at a time.
Related
I'm using MS Automate to solve an integration challenge between two systems we use in our Project Management lifecycle. I have a custom connector written by the vendor of System A which allows me to create a Flow in MS Automate which is triggered when a record is Created or Updated.
So far, so good. However, the method in the connector provided by System A returns the new or updated record containing a number of fields which contain value GUIDs as the fields are 'choice' type fields e.g. Department, Status etc. What I end up with is a record where Status = "XXXXXX-000000-00000-00000" etc. The vendor also provides a restful API endpoint which I can query, which returns a JSON collection of fields, which include a 'Choices' section for each field of this type which is a standard JSON which looks like:
{
"Id": "156e6c29-24b3-4413-af91-80a62a04d443",
"Order": 110,
"InternalName": "PrjStatus",
"DisplayName": "Status",
"ColumnType": 5,
"ColumnAggregate": 0,
"Choices": {
"69659014-be4d-eb11-bf94-00155df8457c": "(0) Not Set",
"c30c50e5-51cf-ea11-bfd3-00155de84703": "(1) On Track",
"c40c50e5-51cf-ea11-bfd3-00155de84703": "(2) At Risk",
"c50c50e5-51cf-ea11-bfd3-00155de84703": "(3) Off Track",
"6a659014-be4d-eb11-bf94-00155df8457c": "(4) Not Tracked"
},
Technical problem:
What I have is the GUID of the choice (not the field). I need to take the GUID, in this case "6a659014-be4d-eb11-bf94-00155df8457c" and translate it into "(4) Not Tracked" and store this in a variable to write to a SharePoint list. I need to do this for about 30 fields which are similar in the record.
I've created the flow and the connector has given me the record with a list of fields, some of which contain value GUIDs. I know which fields these are and I have the Display Names of these fields.
I have added a HTTP call to the provided API endpoint (lets call it GetFields), which has returned a 200 response, the body of the response containing a JSON collection of the 50 or so fields in System A.
I can't work out how to parse the body of the response for the GUID I have for each field value and ensure I have the right corresponding text value, so I can then write it to a field variable, and then create a SharePoint record, all wrapped up in an MS Automate flow.
I hope I've understood you correctly but from what I can work out, you want to dynamically select the value of the choice from the GUID you've been provided (by whatever means).
I created a small flow to prove the concept. Firstly, these two steps setup the scenario, the first being the GUID you want to extract the choice value for and the second being the JSON object itself ...
The third step will take the value from the first variable and use it dynamically in an expression to extract that key from the JSON and return the value.
This is the expression ...
variables('JSON')?['Choices'][variables('Choice ID')]
You an see I'm just using the variable in the path expression over the top of the JSON object to extract the key I want.
This is the end result ...
I have a question regarding best practices to insert Documents in MongoDb.
In my data source the key "myData2" can be null or a string. Should I add "myData2" as null to my database or is it better to leave the value out if not defined? What is the "clean" way to deal with this?
[{
"myData1": "Stuff",
"myData2": null
}]
Since MongoDB permits fields to be added to documents at any time, most (production) applications are written to handle both of the following cases:
A new field is added to the code, but the existing data doesn't have it, and it needs to be added over time to the existing data either on demand or as a background process
A field is no longer used by the code but still contains values in the database
What would your application do if the field is missing, as opposed to if it's set to the null value? If it would do the same thing, then I suggest not setting fields to null values for two reasons:
It streamlines the code because you only need to handle one possibility (missing field) on the reading side, instead of two (field missing or null)
It requires less storage space in the database.
Anyone been able to successfully update the custom_field_values for a matter via Clio's API?
I'm trying to update the value for custom_field_values under a single matter. I'm able to send a JSON string using PATCH and update the default values for a matter like location or description using the following format
{"data":{"location":"Orange"}}
But when it comes to updating a "custom field value" I'm getting a 422 Unprocessable Entity error. I'm following Clio's v4 API Documentation and my understanding is that to update a custom_field_value you need the following JSON:
{"data":{"custom_field_values":[{"id":658213,"custom_field":{"id":139385},"value":"New Value Goes Here!"}]}}
However here is the message coming with the 422 error:
{"error":{"type":"ArgumentError","message":"An invalid argument was supplied: invalid custom field value id provided, acceptable format is <type>-<unique id>"}}
I can't interpret the part suggesting the acceptable format!
I've also tried sending the JSON in the following format which is closest to Clio's V2 API Docs for updating a custom field:
{"data":{"custom_field_values":[{"custom_field":{"id":139385},"value":"New value goes here"}]}}
But then this is what I get back:
{"error":{"type":"ArgumentError","message":"An invalid argument was supplied: custom field value for custom field 139385 already exists"}}
Please note that this is being tested in POSTMAN regardless of my development environment. I appreciate your response!
I've successfully created queries to update custom field values in matters many times, and these run all the time for me. I've compared your json to some examples of the json I'm successfully sending. Your syntax appears correct, but there's enough missing for me to only guess at where your mistake might be.
First, you're sending a PATCH to https://app.clio.com/api/v4/matters/{matter id}.json right? It took me a while to learn that you can't update the value of a matter's custom field with a query to https://app.clio.com/api/v4/custom_fields/{id}.json.
Second, just to clarify, the 658213 id you used above (the first id field) should be the unique id of this instance of your custom field. You won't get this until you've created an instance of the custom field particular to this matter. The second id field, where you've put 139385 is the id for the custom field itself, which you could get with a query to https://app.clio.com/api/v4/custom_fields.json.
If you're looking in the V.4 docs under Custom Fields, you won't find this, or at least I didn't. BUT you can find it in the intro section to the Matters portion fo the documentation: https://app.clio.com/api/v4/documentation#tag/Matters
Hope this helps. I'd imagine someone at Clio could help by verifying your error string is delivered when you have an incorrect custom field value unique id.
To further clarify Jacob's answer for everyone else:
custom_field{id} is the id given to a custom_field when it's created and will be the same for all matters or contacts it's used in.
custom_field_value{id} is the id given to an instance of the custom_field added to a particular matter and unique only to that matter
To add a custom_field to a matter for the first time the following format is used:
{"data":{"custom_field_values":[{"custom_field":{"id":123456},"value":"string or integer depending on the type of CF"}]}}
To update a custom field already added to a matter the following format should be used:
{"data":{"custom_field_values":[{"id":"text_line-1234567", "custom_field":{"id":123456},"value":"string or integer depending on the type of CF"}]}}
To delete a custom field already added to a matter the following JSON format is sufficient:
{"data":{"custom_field_values":[{"id":"text_line-1234567", "custom_field":{"id":123456},"_destroy":true}]}}
Format for updating a custom field already added to a matter:
{"data":{"custom_field_values":[{"id":"unique_instance_of_your_custom_field", "custom_field":{"id":'custom_field_id'},"value":"value which should be updated"}]}}
Here, the first id field should be the unique id of this instance of your custom field. To get this value follow this documentation section, app.clio.com/api/v4/documentation#tag/Matters and the second id field is the id for the custom field itself.
I am pretty new to both Swift and Firebase, and I am attempting to make a simple app using Firebase as the backend. As far as I know, there is no memory-efficient way to use the numChildren() function without loading every single child into memory for counting, so I am implementing my own simple counter for the number of "Events" that have been created in my app.
The documentation for Firebase states that the childByAutoID() method should be used for updating lists in multi-user applications. I am assuming it adds a timestamp to the requested update and does them in order.
My question is whether it is necessary to use childByAutoID() when only updating a SINGLE field in a multi-user application. That is, will there be conflicts on my numEvents field if I do:
dbRef = FIRDatabase.database().reference()
dbRef.child("numEvents").setValue(num)
Or must I do:
dbRef = FIRDatabase.database().reference()
dbRef.child("numEvents").childByAutoId().setValue(num)
In order to avoid write conflicts? My only real confusion is that the documentation for childByAutoID stresses that it is useful when the children are a list of items, but mine is only a single item.
If you are only updating a single field you should not be using childByAutoId. To update a child value for an object, you need to obtain a reference to that object somehow, perhaps by a query of some sort (in many cases you will naturally already have a reference to the object if it needs to be changed) and you can change the value like this:
dbRef.child("events").child(objectToUpdateId).child(fieldToUpdateKey).setValue(newValue)
childByAutoId in this context would be used to create a new field like:
dbRef.child("events").childByAutoId().setValue(newObject)
I'm not exactly sure how this applies to your situation, but those are some descriptions of how to update a field, and use childByAutoId.
What childByAutoId does is create a unique key for a node, to avoid using the same key multiple times and then creating data conflicts like inconsistency (not write conflicts) to avoid write conflicts you use the transaction blocks.
The best way to learn is to try it out
If num == 1 , in the first example the result will be
dbRef:{
numEvents:1
}
While the second will be
dbRef:{
numEvents:{
//The auto-generated key
KLBHJBjhbjJBJHB:1
}
}
The childByAutoId would be useful if you want to save in a node multiple children of the same type, that way each children will have its own unique identifier
For example
pet:{
KJHBJJHB:{
name:fluffy,
owner:John Smith,
},
KhBHJBJjJ:{
name:fluffy,
owner:Jane Foster,
}
}
This way you have a unique identifier for cases where there is no clear way with the item data to guarantee it will be unique (in this case the pet's name)
Few things here:
childByAutoId is not a timestamp. But is used to create unique nodes in any given node.
Use case of childByAutoId :
You have messages node which stores messages from multiple user who are involved in a group chat. So each user can add messages in the group chat so you would do something like this each time user sends message:
dbRef = FIRDatabase.database().reference()
dbRef.child("messages").childByAutoId().setValue(messageText)
So this will create a unique message id for each message from different users. This will kind of act like primary key of message in normal databases.
The structure of database will be something like this:
messages: {
"randomIdGenerated-12asd12" : "hello",
"randomIdGenerated-12323D123" : "Hi, HOw are you",
}
So in your case your first approach is good enough! Since you dont need unique node for counting number of events added.
In CRM, when I'm, trying to set up a work flow, I get to choose the timeout to be related to a certain entity's creation time. There are three fields to relate to.
Record Created On
Created On
Modified On
While the last one is very obvious, I can't see any logical difference between the two others.
The difference is that Created On (createdon) is filled out automatcally by the server when you actually create the record, while Record Created On (overriddencreatedon) will usually be null (unless the record was imported into CRM and you chose to explicitly override the record creation date to match when it was created in another system).
You should use the first and skip the latter, as it's not supported (as far I've got it right when I talked to a MVP about it). Why it show, she had no idea and neither do I. Maybe #JamesWood has a shot. He usually does. (sucking-up in progress)
I've never used the latter and I believe you'll keep your hair off-grey and on-head if you stick to the same approach.
From the SDK:
The createdon attribute specifies the date and time that the record was created. To import data in the createdon attribute, map the source column that contains this data to the overriddencreatedon attribute.
During import, the record’s createdon attribute is updated with the value that was mapped to the overriddencreatedon attribute and the overriddencreatedon attribute is set to the date and time that the data was imported.
If no source value is mapped to the overriddencreatedon attribute, the createdon attribute is set to the date and time that the data was imported and the overriddencreatedon attribute is not set to any value.
Link to BlogSpot
Link to Social MSDN