I'm trying to clean a retired version of an older service I created in CAM, but it's still showing up in the ICP catalog. Is there some way to clear this out?
A retired service in CAM will be displayed in ICP catalog. This is a known issue and we are working with ICP to resolve it. Once retired you have to delete the service via the API as mentioned here:
Delete a service - You can only delete a draft service. After you publish a service, you cannot delete it. However, the workaround to delete a published service is to retire the service and delete it by using API.
https://www.ibm.com/support/knowledgecenter/SS2L37_2.1.0.3/cam_managing_services.html
Issuing a DELETE to /service will clean up the entry from ICP Catalog, but do note that the broker takes some time to update the catalog in ICP, on the order of 15 min:
https://www.ibm.com/support/knowledgecenter/SS2L37_2.1.0.3/cam_common_API.html#getlistservices
Related
I am following this tutorial to build a Cloud Function that triggers a DAG run. I have run into a permission issue. Upon the function being triggered and thus trying to run the DAG, I get a permission error message. It reads as follows:
Service account does not have permission to access the IAP-protected application.
I have followed the recommendation in the tutorial to have a service account with the Composer User role. What am I missing?
Note: I am calling Airflow version 2's Stable REST API and my Composer is version 1.
-Diana
I found a perhaps duplicate question here:
Receiving HTTP 401 when accessing Cloud Composer's Airflow Rest API
As Seng Cheong noted in their answer, the reason for this error is that Google Cloud seems to have issues adding service account IDs that are longer than 64 characters to the Airflow list of users. Upon changing my service account ID to one <= 64 characters, I was able to trigger the DAG successfully. If you can't make your service account ID shorter, then Google documentation suggests adding the "numeric user id" corresponding to your service account directly. The steps for how to do so can be found here: https://cloud.google.com/composer/docs/access-airflow-api#access_airflow_rest_api_using_a_service_account
Best of luck friend
I am using Mule 4 and I am looking to deploy a new application in Cloudhub but it is not allowing me to use the name "customer-api". There is no other application called that in any of the environments and I cannot see it used in API manager either. There was an API called customer-api which has been deleted so not sure if this name could still be cached/ registered somewhere and the entry needs to be cleared.
The only place I can see that name used is in the Anypoint Exchange but wouldn't think that would impact what we are deploying.
Does anybody know what could be preventing me from using that name?
Thanks for any help
Every MuleSoft customer uses the cloudhub, which means it has to be "globally" unique. Try customer-api-randomString and it should work.
Using MFP8, I have truncated MFP_PERSISTENT_DATA and MFP_TRANSIENT_DATA of more than 0.8 million records in live.
Currently, iOS users are facing issues and can see the below logs in server. How to rectify the same
ibm.mfp.server.registration.internal.RegistrationServiceImpl E FWLSE4213E: Client JWT authentication failed - public keys do not match com.ibm.mfp.server.security.shared.webtoken.WebTokenException: Invalid signature
ibm.mfp.server.registration.internal.rest.RegistrationEndpoint E FWLSE4225E: Invalid update self registration request, client signature could not be verified com.ibm.mfp.server.security.shared.webtoken.WebTokenException: Invalid signature
ibm.mfp.server.registration.internal.rest.RegistrationEndpoint E FWLSE4224E: Failed to process registration request.
com.ibm.mfp.server.core.shared.MFPRESTException: 400; headers=[]; body={ errorCode=APPLICATION_DOES_NOT_EXIST errorMsg=Application doesn't exist}
Firstly, random deletion of entries from the MFP-PERSISTENT_DATA is not at all recommended thing to do.for any cleanup of tables, we would recommend you to do so via https://mobilefirstplatform.ibmcloud.com/blog/2018/12/27/purge-mfp-runtime-tables/. suggestions given your current scenario is
1) Starting Nov 2018 level of SDK, Intelligence is incorporated in to MFP SDK to take care of such accidental deletions by cleaning up client context and doing fresh registration. If the customer’s application has a client SDK level that takes care of auto registration , this issue would not appear and MFP SDK will recover from the above error scenario by cleaning up and doing fresh registration . As per information provided below, customer is in a older level of SDK and the auto re registration feature requires an SDK level of Nov 2018 or later.
2) Is there a way to backup / restore data which you have truncated ? if you have taken backup / can you restore and follow proper instructions to clean up as updated in the blog above ?
3)Provided there is no way to restore / cannot upgrade their application to a newer level of SDK , options are to manually clear the application cache /uninstall and reinstall of the application which needs end user actions to recover.
4) Another option is to update your application to setServerURL() method upon this error, but this would again need update to application and careful planning to ensure it is added appropriately only to the exact error scenario in the application logic as it clears the client context completely
https://mobilefirstplatform.ibmcloud.com/api-ref/wl-android-n-java-apidoc/html/refjava-worklight-android-native/html/com/worklight/androidgap/api/WL.html#setServerUrl(java.net.URL)
I have a gatewaymanager (GWM) with 2 worker nodes. When I deploy an API its pushed to the GWM and is available threre --> API-Call works fine.
I decided to synchronize the APIs from the GWM to the worker nodes via rsync. The filesystems under ~wso2/repository/deployment/server on the workernodes are synced and similar to the GWM node.
But when I call the API on a worker node I get this message:
<am:fault xmlns:am="http://wso2.org/apimanager"><am:code>404</am:code>
<am:type>Status report</am:type><am:message>Not Found</am:message>
<am:description>The requested resource (/XXX/1/foo) is not available.
</am:description>
</am:fault>
I also restarted the workes, but same result.
Did I miss something or is there a trigger to load the APIs on the workers to the cache, or something like this?
Faced same issue , when the contents of mediation files were changed.
**Solution which worked for me **
Demote your api to created
Ensure gateway is checked
Redeploy it
The services terminate due to MSMQ not being started at the time they're trying to start up, so the obvious solution would be to set the startup type to automatic (delayed). Rather than going with the obvious solution I'm wondering if there's something I'm doing wrong?
I'm using NServiceBus V5 on Win2012 and started to get these messages on all my installed services after I upgraded to V5 from V4. They're installed to start automatically when the server boots up. This hasn't happened before, and the services start normally if I manually start them.
I don't think you're doing anything wrong--I think it's what you suspect: your service is starting up before the Message Queuing Service is ready.
Assuming the NServicebus is running in NServiceBus.Host.exe, in order to get the service to start after MSMQ, there's a switch that needs to be used when installing the service (I used one line, broke it into multiple lines for readability):
.\NServiceBus.Host.exe /install
/servicename:"service"
/displayname:"display"
/dependsOn:"MSMQ"
I had tried "Message Queing" since that's what was in the service control manager, but I guess it doesn't take the display name. I found that MSMQ was the service name by right clicking on the service and viewing the service name field at the top.
You can set service dependencies without having to reinstall.
use the following command: sc config YOURSERVICENAME depend=MSMQ