While attempting to update a particular field in a contact in Guidewire ContactManager using the API, the field is not being updated. Other fields however are being updated. Example API call info, using Postman:
HTTP method: PATCH; URI: http://localhost:8290/ab/rest/contact/v1/contacts/h2mem:S3U0K_7cuIgA5ZqjRU_qG (port 8290 since I am in TestServer mode; h2mem:S3U0K_7cuIgA5ZqjRU_qG is the id of the contact being updated, obtained from a search call)
body: { "data": { "attributes": { "name":"TestVendor7890", "officeType_Ext": { "code": "government" }, "taxId": "27-1111111" } } }
Yes, I have set the userid and password in Basic Auth. I am sending the body raw in JSON format, settings in Postman made.
So TestVendor789 is an ABCompanyVendor. Before posting this, it has no office type (officeType_Ext) specified. officeType_Ext you can surmise based on the _Ext is a custom attribute. We have other custom attributes and they update OK when using the API. But alas officeType_Ext does not update. We get a 200 as a response so the API thinks everything is fine. It should be returning a 400 or something if it can't update the field. But it isn't.
After posting the above, the name is changed to TestVendor7890 and the taxID is 27-1111111. But the officeType_Ext value remains blank.
I've searched through the GWCC codebase looking for telltale signs of where these various fields may be getting updated. I have even come across something that LOOKS very much like it should be doing the updates; that'd be in ABCoreCustomerAPIHandler.gs in updateContactData(...). I tried adding code that would show that that was being invoked to do the change to the contact info but that code proved to show nothing, that the code was not being invoked.
This leaves me with 2 questions, really... when would ABCoreCustomerAPIHandler.updateContactData() ever get invoked anyway, but more to the point, how are contacts getting updated by calls to the update contact API in the first place? Is the update of contact info being handled by reflection in some kind of esoteric class that is part of the core .jars and that isn't readily viewable by a customizer?
If anyone has ideas, please share.
Answer was found in docs. Please see https://docs.guidewire.com/cloud/pc/202407/cloudapica/cloudAPI/topics/502-ResourceProperties/10-scalar/c_scalars_in_the_schema_configuration_files.html (thanks to Martin Aavik for pointing this out to me.) but in case you can't log in, I'll post here that I had to add an entry to the ...updater.json file in order for the field to be updatable. This appears to have been necessary because the field in question uses an enum to represent the applicable values and it seems that in that case, the updater file has to be edited to include this.
File name: contact_ext-1.0.updater.json
File content:
{
"schemaName": "ext.contact.v1.contact_ext-1.0",
"combine": [
"ext.common.v1.common_ext-1.0",
"gw.content.ab.contact.v1.contact_content-1.0"
],
"updaters": {
"ABContact": {
"properties": {
"paymentAvailability_Ext": {
"path": "ABContact.PaymentAvailability_Ext",
"valueResolver": {
"typeName": "TypeKeyValueResolver"
}
},
"vendorPayInactiveReason_Ext": {
"path": "ABContact.VendorPayInactiveReason_Ext",
"valueResolver": {
"typeName": "TypeKeyValueResolver"
}
},
"officeType_Ext": {
"path": "ABContact.OfficeType_Ext",
"valueResolver": {
"typeName": "TypeKeyValueResolver"
}
}
}
}
}
}
"officeType_Ext": {
"path": "ABContact.OfficeType_Ext",
"valueResolver": {
"typeName": "TypeKeyValueResolver"
}
}
is the new JSON added to the file that allowed the field to be updated.