graphman import order of entity activities

[Michael Mueller]

Dear team.

today we ran into an issue, that is obviously related to the order of entity processing when importing

I am looking for confirmation on my observation and second, if this behavior is the expected one, or if we run into a product issue.

Background:

We tried to imported a bundle with various entities, using the mapping functionality, to define what needs to happen with these entities, either NEW_OR_UPDATE, or DELETE, on an entity level.

The bundle was prepared to import a rollback of a previous deployment. Hence, it consist of

• entities, that needs to be updated/reverted to their previous state, the state before the previous deployment.
• entities, that needs to be deleted, as they were inserted during the previous deployment.
• As mentioned above the mapping data of the bundle defined what needs to be done, on an entity level.

Unfortunately, the import failed.

As far as I can see so far, it failed due to certain dependencies, like:

• A fragment cannot be deleted, if it is still referenced by an encapsulated assertion
• A fragment cannot be deleted, if it is still included in another policy or service

Hence, there seems to be a certain sequence necessary when it comes to deletions. Assumption :

1. delete services first
2. then delete encapsulated assertions
3. then delete fragments

However, even here, one obviously need to take care about the sequence of deleting fragments, as this is not allowed, if a fragment is still included in another fragment.

1st: Is this observation and assumption correct ?

Initially I expected, that the gateway itself takes care about these kind of sequence dependencies.

2nd: Was I just too naive believing that the gateway will take care about the order of deletions?

Thank you and best regards

...Michael

[Raju Gurram]

@Michael Mueller

Observed mutation behavior is expected. Basically, the order of mutation matters, irrespective of the mutation type (CREATE or DELETE). As we all know, there's dependency among the gateway entities. This dependency graph dictates the order of mutation.

Because of which, we've introduced two separate methods for bundle-level mutation.

installBundleEntities --> for installation

deleteBundleEntities --> for deletion (make sure the properties.defaultAction is set to "DELETE" inside the bundle)

Above mutations take care of performing the entity mutations as per their dependency. For more info, please check the "Standard Bundle Mutation Operations" section of the https://techdocs.broadcom.com/us/en/ca-enterprise-software/layer7-api-management/api-gateway/11-1/apis-and-toolkits/graphman-management-api.html

Thanks.

[Michael Mueller]

Thanks a million @Raju Gurram

I'll do some tests with this.

Does that mean, that if you are in the need to update, insert and delete entities, you need to do it in two transactions, one for updates & inserts and one for the deletes?

While the installBundleEntities mutation seems to be the default mutation for "graphman import", I would need to explicitly choose the "--using delete-bundle" mutation for the deletion ?

Thanks

[Raju Gurram]

Yes,

It is always recommended to separate the DELETE mutations from other type of mutations. Of course, if the bundled entities are independent to each other, this restriction can be ignored. 

FYI, installBundleEntities is just an alias to the ordered set of set-based mutations. Whereas, deleteBundleEntities is an alias to the similar set of set-based mutations but in the reverse-order to that of install one.

Thanks.