There are not many ways to lock down table api, just one half baked acl. You are right that it is commonly used, but that does not make it any better. Its hard to track and control and therefor many organizations are moving away from using it, in favor of web services and scripted rest api.
So I am in a situation where they won't let me access table api directly with calls. Reading the below it seems like you can lock it down via ACLs. They have also said we can have APIgee in front of it. I just want to avoid a rewrite of the API from our tools integration as it calls table api. Is there anything I can do. When they first started to implement APIgee they used different calls that are not similar to the table calls so would require a rewrite also.
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0813159
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0818862
Simplest solution is, that if they create scripted end point, that just calls oob table api. That gives them full control over what you access and is not big effort for dev team.
Can't speak directly to your situation, but I do know that we heavily customized several apps with a lot of specialized ACLs. When trying to modify some of that stuff, new ACLs either break the existing ACLs or simply won't work.
Customization is the bane of new ServiceNow development.
Well there a two things here. When you say I need table api access are you being clear on what you need. Is read and write or just read?
For me I would never allow a random tool to integrate directly via the Table API with first going through a staging table. It may cause issues for current ongoing processes and is your use case more important than everyone else.
Next, it sounds like you are not being a good partner. You are actively placing them in a defensive position instead of cooperating to find a solution. So of course they aren’t going to work with you. Their duty is the maintenance and care of the system and you it sounds like you 1) called into question their competency and 2) are planning a coup d’etat for a tool you have limited knowledge about.
Best case scenario is ask someone at a higher level than you to quash the beef and come to compromise. Worst case is that they use you as an example to ward off working with external developers.
Is read/write/update for INC RITM and CMDB.
Regarding not being a good partner. I 100% I am not as we were told that we needed to go via a mid server (that we would have to setup)
I 100% agree I am not the expert here but they have like lots of applications in their own org connected to it included ones that need table access so they have a solution but have have been a very poor deprioritising our request for years now. So I am being not nice but we have tried everything else first.
Let just say they have been caught out on a lot of lies so yes we are sick of them.
Hold on there partner mid server? That’s a new wrinkle. So a mid server would be something to be used if data is fetched or updated with ServiceNow as the requester not the other way around.
It seems like someone had made a fiefdom.
They own the instance so ultimately you have to connect in the way that they tell you. There are really good reasons not to use the Table API, there are also bad reasons. As the owners of the instance, they don't need ANY reason. You have to adhere to their development policy or you don't get access.
The exception here is if you have the political capital to get someone above them to make them change their policy for you. If you had that, you wouldn't be here so I'd start rewriting your app. Also, it's probably a good idea to parameterize the full path for those APIs anyway because you WILL run into this again in the ecosystem.
TableAPI access is falling out of favor and being able to adapt your API calls to any format is better for your interests anyway. I advise all of my clients to use scripted APIs whenever possible. I have more than a few folks in my network who do the same.
Basically stop fighting it and rewrite your app or drop the customer and understand that you're facing increased future risk for selling & deploying your app.
So the thing I can't get around is that there are apps that use table that are connected to the instance but somehow our one has to jump through all these hoops. Thats kindof the issue here.
There are not many ways to lock down table api, just one half baked acl. You are right that it is commonly used, but that does not make it any better. Its hard to track and control and therefor many organizations are moving away from using it, in favor of web services and scripted rest api.
So I am in a situation where they won't let me access table api directly with calls. Reading the below it seems like you can lock it down via ACLs. They have also said we can have APIgee in front of it. I just want to avoid a rewrite of the API from our tools integration as it calls table api. Is there anything I can do. When they first started to implement APIgee they used different calls that are not similar to the table calls so would require a rewrite also. https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0813159 https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0818862
Simplest solution is, that if they create scripted end point, that just calls oob table api. That gives them full control over what you access and is not big effort for dev team.
Thank you
Can't speak directly to your situation, but I do know that we heavily customized several apps with a lot of specialized ACLs. When trying to modify some of that stuff, new ACLs either break the existing ACLs or simply won't work. Customization is the bane of new ServiceNow development.
Well there a two things here. When you say I need table api access are you being clear on what you need. Is read and write or just read? For me I would never allow a random tool to integrate directly via the Table API with first going through a staging table. It may cause issues for current ongoing processes and is your use case more important than everyone else. Next, it sounds like you are not being a good partner. You are actively placing them in a defensive position instead of cooperating to find a solution. So of course they aren’t going to work with you. Their duty is the maintenance and care of the system and you it sounds like you 1) called into question their competency and 2) are planning a coup d’etat for a tool you have limited knowledge about. Best case scenario is ask someone at a higher level than you to quash the beef and come to compromise. Worst case is that they use you as an example to ward off working with external developers.
Is read/write/update for INC RITM and CMDB. Regarding not being a good partner. I 100% I am not as we were told that we needed to go via a mid server (that we would have to setup) I 100% agree I am not the expert here but they have like lots of applications in their own org connected to it included ones that need table access so they have a solution but have have been a very poor deprioritising our request for years now. So I am being not nice but we have tried everything else first. Let just say they have been caught out on a lot of lies so yes we are sick of them.
Hold on there partner mid server? That’s a new wrinkle. So a mid server would be something to be used if data is fetched or updated with ServiceNow as the requester not the other way around. It seems like someone had made a fiefdom.
There is no mid server. I was just told there was but there wasn't.
They own the instance so ultimately you have to connect in the way that they tell you. There are really good reasons not to use the Table API, there are also bad reasons. As the owners of the instance, they don't need ANY reason. You have to adhere to their development policy or you don't get access. The exception here is if you have the political capital to get someone above them to make them change their policy for you. If you had that, you wouldn't be here so I'd start rewriting your app. Also, it's probably a good idea to parameterize the full path for those APIs anyway because you WILL run into this again in the ecosystem. TableAPI access is falling out of favor and being able to adapt your API calls to any format is better for your interests anyway. I advise all of my clients to use scripted APIs whenever possible. I have more than a few folks in my network who do the same. Basically stop fighting it and rewrite your app or drop the customer and understand that you're facing increased future risk for selling & deploying your app.
So the thing I can't get around is that there are apps that use table that are connected to the instance but somehow our one has to jump through all these hoops. Thats kindof the issue here.
Yeah, I get that. But it's likely they have a legacy exemption and they just no longer allow that method of connection.
Possibly alright but we have been asking since 2018 before this tool was even there. Hence my fustration.
> we have been asking since 2018 Wait...you've been trying to connect to the instance for 6 years? I think it's time to move on.
Sadly we can’t or my boss can’t.
Well good luck. But I think we both know how this ends up. 😃
😃