Hi Felix,

This could be due to a limitation in the generated API Documentation (which is based on the OpenAPI spec) and not the actual API itself. The projection you are using seems to be correct since its used by the web client as well.

The problem is most likely that the documentation does not pickup arrays beyond the first level. So the first level array CustomerInfoSet/CustomerAdresses has endpoint information but not the second level array CustomerInfoSet/CustomerAdresses/CustomerDocumentTaxinfoArray.

Reference_CustomerDocumentTaxInfo cannot be used for this as its only a read-only endpoint.

Perhaps as a workaround you can use Developer Tools in your browser to figure out the payload data and types sent from the web client to the REST endpoint shown in your second screenshot above. The HTTP operation will be a POST or PATCH in this case since you are either creating or updating a record.

Hope this helps,

/Rifki

Hi @KleinApps  (and @Rifki Razick )

As Rifki says, it seems like you’re using the correct api call, but working with these arrays past the first level is tricky - as there’s limited docs and navigating thru the metadata is tricky.  One starting point though is that you’re generally not permitted to update reference tables directly and you have to go through these more complex structures.

The good news is that we have created a special parameter in the Boomi IFS connector to allow you to manage API calls of any depth, but it’s a little complicated.  Best go get a coffee at this point as this gets a little long.

Firstly, as you know, in the connector, we added the ability to automatically create an object and associated profile for two level arrays.  In this case, you can import an object called 

CustomerInfoSet->CustomerInfoAddresses

which is what you’d use if you wanted to update CustomerInfoAddresses.  However, here we want to update a child of CustomerInfoAddresses - i.e. CustomerDocumentTaxinfoArray.

Here, we have to manually construct the part of the call after CustomerInfoAddresses and pass it to the connector using the special connector property called “Supplemental Entity Sets and Variables”.

So, let’s take an example using the RACE demo data.  Let’s assume we want to create is

/int/ifsapplications/projection/v1/CustomerHandling.svc/CustomerInfoSet(CustomerId='FR_AIRBUS')/CustomerInfoAddresses(CustomerId='FR_AIRBUS',AddressId='SAINT MARTIN DU TOUCH')/CustomerDocumentTaxInfoArray(CustomerId='FR_AIRBUS',AddressId='SAINT MARTIN DU TOUCH',Company='10',SupplyCountryDb='GB',DeliveryCountryDb='*')

We want to create a “Supplemental Entity Sets and Variables” property of

CustomerDocumentTaxInfoArray(CustomerId='FR_AIRBUS',AddressId='SAINT MARTIN DU TOUCH',Company='10',SupplyCountryDb='GB',DeliveryCountryDb='*')

We do that using a Set Property

Then we use a create operation on CustomerInfoSet->CustomerInfoAddresses, supply the keys to this as normal via a map, and the connector will append the supplemental string onto the end.

You’d likely want to replace the response profile of the operation with the response profile of Reference_CustomerDocumentTaxInfo, since that’s actually the object we’ll be seeing as the response.  You can get this profile by saving it after you create a Get operation - i.e. just do a Get simply to save that profile.

So far, not too bad (I hope), but there’s one more nuance since we need to pass the update fields in the body.  The easiest way to do this is to remember that the request profile of the operation here is actually providing data to the top 2 level of the arrays CustomerInfoSet->CustomerInfoAddresses to create the keys, but realise that we can manually edit this profile to add the extra fields we want to pass to CustomerDocumentTaxInfoArray as the body.  The keys for the CustomerDocumentTaxInfoArray come from the supplemental string we created above.  So, here, we’d add an extra field onto the CustomerInfoSet->CustomerInfoAddresses Request profile of VatNo, so that we can pass data into it easily.

So, let’s look at a more real example to create the same url we mention above.

The “InboundMessage” shape is just dummy data

{
"VatNo":"12345",
"CustomerId":"FR_AIRBUS",
"AddressId":"SAINT MARTIN DU TOUCH",
"Company":"10",
"SupplyCountryDb":"GB",
"DeliveryCountryDb":"*"
}

Here, we’ve got the update data and all of the keys.

Then we create the supplemental string.  To make this easier, I created a JSON profile to match the inbound shape, created a Dynamic Document Property from the various JSON elements, and then use that to populate the supplemental string

Then

Now we can create the map to populate the keys for the update, but also to only pass the fields we want in the payload.  We now don’t want the keys for CustomerDocumentTaxInfoArray - they’re specified in the supplemental string, so they’re not mapped.  We want to create a payload to pass to the IFS Connector shape which contains the keys for the object the connector thinks it’s working with (CustomerInfoSet->CustomerInfoAddresses), plus any additional fields we want to pass as payload to the object we’re really working with.

The VatNo field in the source is mapped to a VatNo field in the Modified Update Request profile - i.e. the Update Request profile from CustomerInfoSet->CustomerInfoAddresses to which I’ve manually added an extra object called VatNo.

So, the output of the map shape will be a payload of 

{
  "AddressId": "SAINT MARTIN DU TOUCH",
  "CustomerId": "FR_AIRBUS",
  "CustomerInfo_CustomerId": "FR_AIRBUS",
  "VatNo": "12345"
}

And we set a property on the connector of 

CustomerDocumentTaxInfoArray(CustomerId='FR_AIRBUS',AddressId='SAINT MARTIN DU TOUCH',Company='10',SupplyCountryDb='GB',DeliveryCountryDb='*')

And, that’s that.

If you, or anyone, wants this sample process, ping me a note and I can copy it over to your Boomi account.

Peter