OSCM multi tenancy issue for modify subscription call

[pujarisat]

Hi Team,

We found one other issue related customer AD account .

Use case : We are able to modify the subscription first time using UI successfully using customer AD account and we have try to modify second time same subscription it gives error.

please find the log file attached server.log

[GoebelL]

@pujarisat Please share with us, if you have any further information here

From given log I can hardly make relation with the IdP system used here. Obviously authentication succeeded with this AD account, otherwise first modify operation wouldn't have been possible. However, there is an issue with repeated subscription modification in 17.4 (issue is tbd).

We are working on it.

[GoebelL]

This seems related to issue #893

[pujarisat]

Hi Team ,

I have shared all domain log in email and let us know if anything more info need from our end .

-Thanks Satling

[StavrevaS]

This is multitenancy problem. There are 2 tenants in the test environment, the default one and a customer tenant. How to reproduce:

1. Login to marketplace as a customet tenant user;
2. Subscribe to service (the customer admit is set automatically as subscription owner);
3. After the subscription is in active state (green, ready), modify the parameters;
4. After the subscription is in active state (green, ready), modify the parameters again;

The second modification ends with OperationFailedException.

Just short explanation how the asynchronous subscription modification is working. Before the provisioning call to APP, the subscription configuration to be modified (parameters, unit, owner, id..) is temporary saved to a separate db table (modifiedentity). If APP reports a successful modification, the new configuration is written into the subscription and the temporary records are deleted. In failure case, the temporary records do need need to be applied and are deleted. So in any case after the asyncronous provisioning is finished, there should be no records in "modifiedentity" table for this subscription.

The error situation is the following:

• One of the temporary records about subscription configuration is about the subcription owner. This is a user from the customer tenant. APP is operated by the platform operator and belongs to the default tenant. It uses a user from the default tenant for the callbacks (SubscriptionService, complete or abort the modification).
• The server.log shows that the second modification finds temporary records in the "modifiedentity" table for this subscription (we have inconsistent state, they should be deleted after the first modification is finished). APP log shows successful modification and wants to complete the provisioning. In the SubscriptionService.completeAsyncModifySubscription() stack, there is a method call which applies the new configuration to the subscription and then deletes the temporary records - ModifyAndUpgradeSubscriotionBean.updateSubscriptionAttributesForAsyncUpdate(). The subscription owner in the temporary records is the original one from the customer tenant. The method tries to find this user into the tenant of the current user performing the SubscriptionService method call and this is the APP user from default tenant. So we have a user search where we try to find a user from the customer tenant into the default tenant. As a result ObjectNotFoundException is thrwon, but it does not rollback the transaction. So the subscription will go into the active (ready) state, but the temporary records of the first modification are not deleted.
• The second modification will find inconsistent state in the database - NonUniqueBusinessKeyException for the "modifyentity" record. NPE is thrown since there is no appropriate entry for ModifyEntity.java entity for such case (DataServiceBean.java, DomainObjectException.ClassEnum class2Enum() method)

So the following problems should be fixed:

1. Avoid NPE in case of NonUniqueBusinessKeyException for ModifyEntity domain object;
2. Search the subscription owner into the tenant of the customer organization to which the subscription belongs.
3. Consider transaction rollback in cases where the subscription can be left in inconsistent state otherwise.

Note about 2: Be sure to fix it properly for SSO and internal mode.

[StavrevaS]

The issue is fixed with searching the owner (user) in the tenant of the customer organization which owns the subscription.

[GoebelL]

@SylviaDehn Please verify with last unit build

[ghost]

[Build] 17.3.1 verified in multi-tenant environment