Support function import in addChangeSet method

[KurtStauffer]

According to this documentation (for the example "PUT: Update Additional IDs and their Permissions and Subscriptions Within One Changeset") in order to update an additional id you must delete all additional ids via a function import and then re-add all including the updated one.

To accomplish this with the API I would do something like this...

service
    .batch()
    .beginChangeSet()
    .addFunctionImport(deleteAllAdditionalIdsFunction)
    .updateAdditionalIDs(additionalId)
    .endChangeSet()
    .executeRequest(destination);

However, I need to be able to configure my requests further, for example, to add headers. According to your documentation I can use .addChangeSet to accomplish this...

service
    .batch()
    .addChangeSet(...)
    .executeRequest(destination);

The problem is that addChangeSet only supports FluentHelperModification but not FluentHelperFunction. Since both of these classes extend FluentHelperBasic would it be possible to allow addChangeSet to support function imports as well?

Thank you for your consideration!

[Johannes-Schneider]

Hi @KurtStauffer,

thanks for reaching out to us.

Unfortunately, as you've already figured out, our current high-level implementation does not (yet) support adding FluentHelperFunction - I have created a new item in our backlog to close this feature gap.

In the meanwhile, you can use our generic ("low-level") OData client to workaround this limitation:

HttpDestination destination = DestinationAccessor.getDestination("myDestination").asHttp();
HttpClient httpClient = HttpClientAccessor.getHttpClient(destination);
DefaultBusinessSituationService service = new DefaultBusinessSituationService();

ODataRequestBatch genericBatchRequest = service.batch().toRequest();

ODataRequestAction genericAction = (ODataRequestAction) service.sendActionStatus().withHeader("key", "value").toRequest();
ODataRequestResultMultipartGeneric result = genericBatchRequest
        .beginChangeset()
        .addAction(genericAction)
        .endChangeset()
        .execute(httpClient);

Please let me know whether that helps.

Best regards,
Johannes

[KurtStauffer]

Thanks @Johannes-Schneider for the quick response. We are actually currently using the low-level API for this and were hoping we could refactor to use the high-level. Thank you for creating a new item in your backlog for this and we will revisit if/when it is complete.

Thanks again,
Kurt

[newtork]

Hello @KurtStauffer,

Please excuse my confusion, can you check whether your initial idea is working?

service
    .batch()
    .beginChangeSet()
    .addFunctionImport(deleteAllAdditionalIdsFunction)

I would expect this to work(?). Can't you add custom headers to deleteAllAdditionalIdsFunction object? Or will they be ignores?

Kind regards
Alexander

[KurtStauffer]

@newtork thank you for your question. I realize that I wasn't very clear on what we are trying to do. We are actually needing to make multiple requests in a single change set and those other requests do require custom headers to be set. While this does work for the example you gave, it does not work for the non function imports within the same change set...

service
    .batch()
    .beginChangeSet()
    .addFunctionImport(deleteAllAdditionalIdsFunction) // headers can be added to the function helper
    .updateAdditionalIDs(additionalId) // no option to add headers here
    .endChangeSet()

This was actually an issue that I raised a while back and the workaround at that time was to use the lower-level API, which we are doing now.

Since then, they have updated the API to include the addChangeSet(...) method to support custom headers for each request and we are wanting to move away from the low-level but are once again running into problems outlined in this issue.

I hope this helps clarify things.

Cheers,
Kurt

[newtork]

Hi Kurt,

Thanks for the clarification again. We will harmonize the OData V2 and OData V4 API in the next major release, that will be consumable early Q3 / 2022. This will also fix the problem(s) outlined in this issue. As a result you will need to adjust the code for the high-level VDM call, once you update Cloud SDK.

We are actually currently using the low-level API for this.

The low-level API will likely not face any significant changes.

we could refactor [the code] to use the high-level [API].

The open question:
Do you need a solution now for high-level, that will be outdated in Q3 / 2022 already?
Or is it okay for you to wait a few months to have a proper long-term solution?

Kind regards
Alexander

[KurtStauffer]

Hey Alexander,

Thank you for the follow-up. We're totally fine continuing to use the low-level for the foreseeable future and it is working for our business needs. I just personally have that itch to clean and consolidate things 😉

Thanks for all you do!

Cheers,
Kurt