Upgrade Existing Lightning transfer error: bad response 400 -- in UAT

[vanessacalderon]

I tried to transfer case 1450 to Install New Lightning and I received an error. I checked the configuration in SF and the configuration is correct. City Worker should be looking at the Selected Types in the Service Activities Transfers in the Transferable Service Types, not looking at the Selected Types in the Service Request Transfers. See second screenshot with example.

[jqr]

This is the first I'm hearing that there are different lists of transfer destinations for the two different types of transfers within Incapsulate.

We were instructed to query /311/v3/services/.../activities-transfer-types.json and then use that result with /311/v3/requests/.../transfer.json which given the screenshot above, looks like a mismatch.

The question is, should we be querying the list of destinations from somewhere else, or use a different API for transferring?

[vanessacalderon]

@Gerardovillanueva

[vanessacalderon]

Hi Elijah, I do not recall those instructions, but we were instructed to put the available SRs for transfer AND reallocate in the lower boxes: Service Activities Transfer (the same goes for reallocation: Service Activities Reallocations). According to what we were told, the SRs/Queues that CW looks at are in those boxes, not the top boxes.

[Gerardovillanueva]

While transferring a duplicate case on UAT I got the following error:

Even tho its a duplicate the next outcome did show up!

[vanessacalderon]

@jqr Gerardo just added another example of an error because it is looking at the Service Request Transfer boxes instead of the Service Activities Transfer boxes.

[jqr]

Understood. No more examples needed. Just awaiting instructions from Incapsulate on this:

Should we be querying the list of destinations from somewhere else, or use a different API for transferring?

[vanessacalderon]

@karthikakula -- Karhtik please ask Ipshita to get a GitHub account to join. See the issue here. There is a discrepancy on what was told to Connected Bits and what was told to CoB. Can you take a look at this please?

[jqr]

@karthikakula and I discussed this during the call with CoB today and he asked for the documentation we were using. Here's the documentation we have around the destinations and API calls.

1. From Karthik, September 11, 2017. Subject: API

   I finished all of these over weekend. Give it a try on devint2. 1) Activity Transfer Types: /services//activities-transfer-types.json?api_key= 2) Activity Reallocate Queue: /services//activities-reallocate-queues.json?api_key=

2. Postman shared example

   

3. The diagram @gackerjr created:

These are in chronological order with the final one being at least a week of research and meetings.

[vanessacalderon]

So you are saying that instead of PUT/311v3/requests/[REQUESTID]/transfer.json there should be another PUT with some reference to Service Activity Transfers? And the same goes for reallocation.

[jqr]

@vanessacalderon Yeah, that's my guess.

[vanessacalderon]

@Jailalwani - good, we are one step closer. So, there should be a PUT that Karthik has in his documentation? Or since there is no such a thing, G. Acker assumed that was the only PUT available?

[swagattalsania]

@jqr /311/v3/requests/.../transfer.json currently supports only service request level transfers. In order to support transfers happening from service activities, we are proposing a solution to add an additional URL parameter activities=true. So the URL endpoint would look something like /311/v3/requests/..../transfer.json?activities=true&api_key=.

Besides this, reallocation is already supported from activity level with the endpoint /311/v3/requests/:requestNumber/activities/:activityCode.json. The documentation is already shared with everyone. Here is the link to the document for reference: https://docs.google.com/document/d/1-6WY2GzMLqT5C7GUD7TVjdG6mLNcXs4B4O8aQQORD9s/edit

Let us know your thoughts.

[jqr]

Please consider consolidating the documentation. Searching emails for snippets of documentation is hugely wasteful of all of our time.

I overlooked that Reallocate document when searching for all documentation on this feature. We are actually operating off of it. So Reallocates no longer have an additional PUT call after the Activity PATCH.

@swagattalsania the asymmetry between these approaches feels odd, but I can pass the activities=true if that would work well for you.

[swagattalsania]

@jqr Sure. We will setup a single API reference.

We see your point regarding the asymmetry but for this release let us go with the proposed approach that we can provide using a patch release and we can further define the specs for this in the future releases to make it consistent.

[jqr]

👍

[vanessacalderon]

again, the transfer action was broken into two sections by Incapsulate in the same fashion as reallocation. Transfers as reallocations, can happen at two levels: case and activity. Activity is the only section that CW participates in. Not said in technical terms, sorry.

[Jailalwani]

@jqr Sure. We will setup a single API reference.

We see your point regarding the asymmetry but for this release let us go with the proposed approach that we can provide using a patch release and we can further define the specs for this in the future releases to make it consistent.

@swagattalsania @karthikakula Need consolidated one documentation on the Incapsulate API capability. Absence and lack of understanding is resulting in multiple dialogues. Example: Transfers are currently supported only at service request level and not at Activity level. Reallocation is already supported from activity and as well from the Service request level. Can you please provide the JIRA DEFECT # here for the reference for future patch release?

Do we have one centralize artifact that describes the alternate workaround we are taking such as proposed in this ticket and how in future it will be addressed?

Thanks Jai @jqr @davemitchell

[Jailalwani]

@swagattalsania Any updates ? Is this your proposed short term solution? /311/v3/requests/.../transfer.json currently supports only service request level transfers. In order to support transfers happening from service activities, we are proposing a solution to add an additional URL parameter activities=true. So the URL endpoint would look something like /311/v3/requests/..../transfer.json?activities=true&api_key=.

I appreciate your timely responses.

Regards Jai @jqr @karthikakula

[Jailalwani]

@swagattalsania @karthikakula Any updates?

Thanks Jai

[Jailalwani]

@karthikakula I see this as defect, what is holding us working on this issue?

Thanks Jai @vanessacalderon @jqr @davemitchell @swagattalsania

[vanessacalderon]

JIRA BOS311API-191 references this same issue. The next steps:

Incapsulate designed this Transfer page to divide permissions for transfer at case level and activity level for ease of use and efficiency so the integrators did not have to get the list of ALL SRs and try to display the huge list in a mobile screen. Then, if this is the original intent, why don't the integrators get the API call that corresponds to their custom list of SRs? What is the point of designing this if they cannot access it?

My next step would be to have integrators get the list for the Service Activity Transfers since they have it in SF just for them.

[Jailalwani]

@vanessacalderon How do you foresee this issue to be resolved by providing the list for the Service Activity Transfer to CB? I am sure I am missing something Thanks Jai @jqr

[davemitchell]

@Jailalwani see @swagattalsania answer from 20 days ago...

Sure. We will setup a single API reference.