Can someone guide me where to found some docs or example on using REST API when multi-tenancy is one?
Strugling to construct a post to create a request.
I have added the <tenant REL_ATTR="U'E9B777A4F5573B4A9828311D4DE410B7'"/> to the body of my request but always get back below error.
com.ca.sdm.dal.sql.DALException: The provided resource identifier returned multiple matches. Try providing the id or REL_ATTR.
I did check all the related attributes that I sending and they are all unique. Using id or REL_ATTR vs. COMMON_NAME didn't help.
note that I have not problem to create request in single tenant instance (with of course no tenant in the body)
Using 14.1 so tenant is suppose to be supported in REST API (since 12.7 patches if I recall)
Thanks in advance
I created a contact in one of my tests with a Tenant specified and it worked just fine with the code below:
<cnt><first_name>James</first_name> <last_name>Bond</last_name> <mobile_phone>007</mobile_phone><userid>bond007</userid> <email_address>email@example.com</email_address> <delete_flag id="4551"/> <tenant id="U'1B0D2350DFCFD149ADFF546F9793BB95'" /> <type id="2308" /> </cnt>
Surely something similar for a ticket should also work...
Thanks Brian for your quick answer.
yes I'm able to create new contact too using any get. but still blocking on the cr object for POSTand PUT.
will try with id vs, REL_ATTR if that help
Will keep you updated.
Progressing but still not there
using id for tenant vs. REL_ATTR give me another error:
com.ca.sdm.dal.sql.DALException: No records found. See application error logs for more details.
.... nothing in log anyway
do you think that permissions may have a link to this?
user for the rest call is part of service provider tenant and ticket to be created in on a sub tenant but was not causing any problem creating contact anyway
Have now tried on a different multitenant instance to eliminate env root acuse but still stuck with same problem.
I can create cnt but not cr/in/pr always return me 400 with no records found
I can't find what I'm doing wrong.
Brian Mathato when you get 2mn, can you test on a cr/in/pr object when the rest user is part of service provider and the customer is in a sub-tenant to confirm that I'm just crazy or this to be a bug.
Note that use id, REL_ATTR or COOMON)NAME provide same result either if in my frist attempt I was initially getting a multiple match.
Which log did you check for errors? If you checked the stdlog, you want to check the jrest.log instead.
Also if you omit the tenant field, does the ticket get created? With this use case,the resulting ticket should belong to the tenant of the affected end user (customer).
I tried a 14.1.04 over here and was able to create a ticket fine. Is it possible that the REST API role you are using doesn't have enough access to search the tenant against which you are trying to raise the ticket against?
<customer COMMON_NAME="servicedesk" /> <description>this a test via REST</description> <tenant COMMON_NAME="My Tennant" />
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><in id="401811" REL_ATTR="cr:401811" COMMON_NAME="253"> <link href="http://hostname:8050/caisd-rest/in/401811" rel="self"/> <priority id="505" REL_ATTR="0" COMMON_NAME="None"> <link href="http://hostname::8050/caisd-rest/pri/505" rel="self"/> </priority> <ref_num>253</ref_num> <tenant id="U'88CDC1879B38A841BE8B085B02EE3322'" REL_ATTR="U'88CDC1879B38A841BE8B085B02EE3322'" COMMON_NAME="My Tennant"> <link href="http://hostname:8050/caisd-rest/tenant/U'88CDC1879B38A841BE8B085B02EE3322'" rel="self"/> </tenant></in>
Thanks for your Reply Raghu
I'm now in fact able to create ticket too and have identified the problem.
Problem is apparently with public data. if your log your ticket on a sub-tenant apparently the public data is not available for that ticket.
Because we have some mandatory field on the ticket and that public category can't be found the ticket failed to create. with error message no record found.
Creating a category with the same name under the sub-tenant make also the ticket creation to fail but with another error message: The provided resource identifier returned multiple matches
Only by creating a new category under this tenant with a unique name fixed the problem.
I will manage like this for now for all the tenanted reference but I do believe if all the statement above are fully true(would like to see someone in another env be able to replicate and confirm) that this is then a bad implementation in the REST-API and be a nightmare for a maintenance perspective(imagine having to create and maintain a tree of unique category for each tenant * 30-40 tenants)
Thank you all for your help.
Great point Jerome. I thought I'd be able to run into that case too.. I got couple of categories, blah (public) and blah (my tenant). I tried to create a ticket against "blah" and yea it did not work.
However, I used the ID and it worked OK -
<customer COMMON_NAME="servicedesk" /> <description>this a test via REST</description> <category id="400106" /><tenant COMMON_NAME="My Tennant" /></in>
If I did not pass the ID it did not allow me and I got the same error.
yep interesting but not practical.
look me a strong limitation of the REST interface in those multitenant instance where in fact the lookup behind don't seems to consider tenant.
Thanks for your time Raghu
Did you already create a support issue for this behavior?
Apologies if I misunderstood your update.
In my case lookup by id worked, but lookup by common name failed because it returned multiple records. I might be missing something obvious, but it seems reasonable that we errored out on the multiple record result?
Hi Raghu and thanks for the follow up
Yes for a technical side this is reasonable to have the error at the output.
However from the functional side this don't appears sufficient to me. As an MSP you would like that the public references are available to any tenants (look for me to be the purpose to be public).
This is how the behavior is either working on the web interface. Then the REST API is adding an unnecessary limitation here.
In many case single reference is to be shared across (for example to enforce consistency across multiple tenants served by an MSP) vs. to be created multiple time.
This is either worse because let's say you duplicate 2 references with the same name in 2 different tenants you may be at the risk as depending of the creation sequence that because the first id returned by the lookup was created into another tenant that will also have a record not found error.
I was glad to see that you can use COMMON_NAME in the REST_API vs. to have to do multiple call like in SOAP but then get frustrated, by up to my view, an unnecessary limitation. This look like we stopped at only a half of the destination...
My 2 cents
Thank you for your time in explaining this further. Yes, I do see the concerns here and how they would impact this from usability of integrations.
We may need to have our product managers check this out a bit more. CarolPiccus or kumra92 any comments on this one further? Thank you !
Hi Jerome/Raghu - I marked Raghu's response as correct, but I think we should generate a "discussion" post from this so that we can keep open communication going forward on how this would be handled best by the product management team.