Error - Migration from 3.5 to 5.0.2

[santhosh bhojraj]

Hi Team, while doing the migration we are getting the following error 

- {"error":{"code":"ValidationException","message":{"lang":"en","value":"The request could not be completed due to data input errors."},"detail":{"errorCode":"483","devErrorMessage":"The request could not be completed due to data input errors.","userErrorMessage":"The request could not be completed due to data input errors.","userErrorKey":"error.validation.entity","validationErrors":[{"field":"ApiGroupIds","error":"Associated API Group of application must be enabled.","key":"error.validation.application.save.apigroup.notenabled"}]}}}

ERROR: The following script error occurred on https://10.205.56.192/template_resources/js/papi-migrator/papi-application.js?releaseId=1613495472 656:17

ERROR: TypeError: itemObj is undefined

Has anyone seen this error

thanks 
Santhosh

[William Forsyth]

Hi Santosh:

Have you got API Plans enabled on the target portal 5.0?   If that is the case API Groups functionality will be disabled and the API Groups would probably have an error migrating.   Normally if I see these errors it is because of bad data on Portal 3.5 that does not map correctly, something like data entities in a pending state.  

Regards, Alex.

------------------------------
Solution Architect - Security & Integration
Broadcom Software Division,
Vancouver, B.C. Canada
------------------------------

[santhosh bhojraj]

Thanks Alex for the help.

We are not able to migrate APIs and complete the migration activity due to mentioned below points.

1.APIs are REST on gateway(version 10.1) but published as SOAP on portal 3.5.

 2. We are unable to change the type from SOAP to REST on portal3.5.
we feel this is the reason it is giving this issue  . Any advice on this kind of scenario 

Thanks 
Santhosh 

[William Forsyth]

That is an interesting problem I have not run into before as usually the two types will match.  There are two ways to do the migration, one in place with a gateway already enrolled with Portal 3.5 and the other with a new gateway which would give you the flexibility to modify what is on the target gateway so they are matching.  The second approach with a new gateway would give you the ability to cutover without impacting the existing platform.  I can see why the migration may fail in this scenario and think you need to find a way to make sure the target gateway has a type SOAP or be able to delete the Portal 3.5 API's before the migration and deal with the issue after the migration. . 

Regards, Alex.

------------------------------
Solution Architect - Security & Integration
Broadcom Software Division,
Vancouver, B.C. Canada
------------------------------

[santhosh bhojraj]

Hi Alex,
Thanks for the support 

SOAP APIs are part of the API Group and after removing the APIs from API Group those should get removed from Applications as well but we still see APIs part of Applications(and API Group still has those APIs).

When we are checking the API Group, SOAP APIs are removed successfully but the API Group in Application is not getting updated. 

Until APIs are removed from the Application, we cannot disable the API i.e. Application count should be zero for API for disabling it. We tried refreshing and restarting the portal but still, Soap APIs are part of the Application. 

Thanks
Santhosh

[William Forsyth]

Hi Santosh:

I believe this is by design so applications do not break unknowingly for those developers that have created applications assuming the API is there.  API's are deprecated and managed carefully so not to break dependencies developers have on them for their applications. 

Regards, Alex.

------------------------------
Solution Architect - Security & Integration
Broadcom Software Division,
Vancouver, B.C. Canada
------------------------------

[santhosh bhojraj]

Hi Alex, 

This is what we did to resolve the issue with help of support . Thought of sharing ...

1. Open /admin?action=list&path=/sitebuilder/content/groups/APIs 

2. Locate apis by id.

3. Click on edit icon and change SOAP to REST in the dialog.

4. After editing, publish icon will appear, click and verify in Portal UI that api type has changed

5. Rerun migration. 

Thanks
Santhosh 

[William Forsyth]

Excellent, thanks for sharing the solution. 

Regards, Alex.

------------------------------
Solution Architect - Security & Integration
Broadcom Software Division,
Vancouver, B.C. Canada
------------------------------