Here is the setup I did
Created a routing configurationenter image description here
Created a queue and associated it with the routing configuration and added a couple of users
enter image description here
Created a service channel for the associated object (GEICO Quote)
enter image description here
Created a GEIO quote and assigned it to the queue created in step 2
enter image description here
logged into Omnichannel as one of the users associated with the queue
Expected Result:
The quote created in 4 would be routed to the user as an Omnichannel work request.
Actual Result:
The work request queue for this user remains empty.
So how do I get something routed using this queue?
So I'll answer my own question. The missing element was a Presence Status linked to the Service Channel. So summarizing what is needed, to save someone's future agony, you need the following:
a Routing Configuration
a Queue that is associated with the Routing Configuration
a user(s) that is associated with the queue (user needs to have a Service Resource and a bunch of permissions -- not gonna go into that here)
a Service Channel that supports the same object that the queue supports
a Presence Status that is associated with the Service Channel
You do NOT need a flow; just changing ownership of the routed record to the queue will route the item.
Related
Currently, I try to send SaleToAcquirerData metadata to the terminal when the order to sync to Adyen Backend, I have checked at Adyen Backend but don't see metadata and my webhook cannot receive metadata
I need to send metadata to the terminal and receive metadata at my webhook
In this answer, I expect that you
Already receive webhooks events and that your webhook is well configured
That you receive core data from webhook events but that the POS related additional data is missing
Have you activated the POS additional data for this specific webhook?
You can do it in the Customer Area, Developer -> Webhook, select your webhook and then "Additional settings".
The UI looks like this :
Save, and exit. Your future webhooks events should contain POS metadata. Please note that you may still receive some events without the metadata that you except, because they were already generated at the time they were created.
EDIT : In case you want to use the API for this, you can also PATCH the existing webhook with additional settings using the new Management API.
While waiting for extra information, your question may be understood another way : You want to access the metadata field of the additional data section of a webhook event.
In that case, these metadata fields should be submitted at the time of payment in the POST /payments request.
You can find more information about this in the Webhooks documentation.
I'm working on a project that consumes Service Now API (Rest). To do so our client has registered us as a user in order to login and make all service calls we need to. This project has an interface where users can login once they have an account on Service Now as well, the username they type to log in has nothing to do with service now by the way, but later they associate theirs service now users to it. They can do some operations through this interface, where all of them are done using the integration user/pass not their service now users theirselves, even because they do not need to share their passwords with us. But it's needed to track the correct user to register on service now and I'm in trouble specifically about commenting on an incident. The endpoint to comment is the following :
http://hostname/api/now/table/incident/{sys_id}
where request body is a json object just as simple as :
{
"comments": "My comment is foo bar"
}
but when this comment is registered on Service Now it is under integration user instead the user which commented. Is there any way I could keep a specific user, considering I already have the user id on Service Now ready to inform it on the request the way it should be.
I tried reading Service Now documentation but had no clue how to solve it, altought I've found something about impersonate
This is happening because you're being proxied through the "Integration User" instead of your own account. As long as this is the case, your comments are going to be attributed to the Integration User.
I can think of two ways to fix this issue.
Ask the client to log you into their system directly as a user.
Implement a special API (Scripted REST API, available in Geneva or later) that allows you to identify the Incident and enter the comment, and then the script forges the comment on your behalf, attributing authorship correctly.
The first solution can be expensive due to possible additional licensing costs.
The second solution will require a willing client to devote 2-3 hours of development time, depending on the programmer.
Firstly, you need an integration user with suffient rights. Our integration user has suffient rights out of the box, but your story could be different. A quick check is to try impersonate as other user using menu.
Login as integration user to ServiceNow instance.
Go to https://{instance}.service-now.com/nav_to.do
Click on username at top right corner. This is a drop down.
There should be at least three menu items: "Profile", "Impersonate User", and "Logout". If you do not have "Impersonate User" in this menu, your integration user miss some permissions. Contact system administrator if you miss this menu item to configure appropriate permissions.
Then you need to find sys_id of user that you want to impersonate. For example:
https://{instance}.service-now.com/api/now/table/sys_user?sysparm_query=user_name={username}&sysparm_fields=sys_id
If you have suffient privileges, you could invoke the folling endpoint with sys id of user that you want to impersonate:
HTTP POST to https://{instance}.service-now.com/api/now/ui/impersonate/{user_sys_id} with body "{}" and content type "application/json". You need to provide HTTP basic authentication to this query as your integration user.
The response code on success is 200. The response body could be ignored. The interesting result of this response is a set of cookies for impersonated user in response headers. These cookies could be used for subsequent REST API calls until they expire. Use some HTTP rest client dependent method to capture them and to provide them to next calls.
For Apache HTTP Client (Java), I'm creating http client context using:
HttpClientContext context = HttpClientContext.create();
context.setCookieStore(new BasicCookieStore());
Pass thing context to impersonation request and to subsequent API calls until I get 401 reply, after that I'm reaquiring cookies. Setting new cookie store is important, as otherwise some default cookies store is used.
Two things to note:
This API looks like internal one, so it could change at any time. If it happens, look for what "Impresonate User" menu item does, and repeat it youselves.
ServiceNow permissions are quite fine-grained, so the target user could lack permissions to perform operation. In some cases, if there is no permission to update the field the operation PATCH on object returns reponse 200, but field is not updated. This introduces a surprising mode of failure when you use impersonation.
I have a REST api written in node which uses HATEOAS. The user is required to have an account before they can access the bulk of it.
They register an account with login details, then login to obtain an access token, and then use that token in order to access any endpoints that aren't register or login.
Issuing a get to the root responds with a directory with available actions.
Q: What is the correct response from register, to tell the client what it can do next (i.e. login)?
register technically creates a new resource on the server so a 201 CREATED and a Location header would seem appopriate. However the login reference isn't the location of the newly created resource.
Should I return 201 Created with a Location pointing to the newly created user (e.g. /myaccount or /users/{id} and then include a login link in the response body?
{
_links: {
self: { href: "what goes here?" },
x:login: { href: "/login" }
}
}
Do I not tell the client at all, and require them to do a get on the application root in order to fetch a list of available endpoints. This should include login anyway. Assuming the client had to do that in the first place to get the register link it should already have login.
Expecting the client already to already have the login link feels uncomfortable as it relies on an assumption of the client's prior activity.
Requiring the client to issue another request to the root directory after registering seems mean, inefficient and unnecessary. If the client has just created a resource it seems only fair that the server should respond with what it can do with it next.
I like to have my api's act no differently than a webpage. If you want the UX of your application to be the user is taken to login after they register, then 302 them from a successful register to the login resource. And upon successful login, 302 to them to the appropriate destination (IE, if they tried to access something with no token, then take them to login, with a destination of the original requested resource). That's and important part to your #3. Having a link off the root that leads to login, but you need to protect all the other links such that they indicate (and link to) a login being required to access the resource. The client app should expect to get this login required response at any time as tokens can (and do) expire at any time.
Following on this, it might make sense to do the JWT as a cookie instead of as an Authorization Header, it would make it a bit easier for the client (they just have to setup a cookie jar)..if the client is say a native mobile app that maintains a single connection setup. If it's server to server, then auth header makes sense. I'd go about supporting both to cover both scenarios.
Continuing on the idea of thinking of the api as a web site. Why have them login after registration at all? Why not have the registering of an account end up with the login token being sent? they just set their user/pass, why make them enter it again? I realize with some more exotic architectures the register service can not perform the login action (perhaps it doesn't have the private key to sign the token), but if it is possible i'd consider it.
If you really want to stick to the 201 header (which is fine, just make sure the docs of your register relationship indicate that), then option 2 is the closest in my opinion. A location header to the URL of the account just created a 201 is pretty standard for creating a user. But, i'd not return what you've supposed there. You're kind of returning a account-created resource (the thing with the login link), but do you really need this custom resource? If you want to give some messaging back to the client (like "Account Created") in that resource then absolutely yes, but you could also just give them back the root resource.
tl;dr; Decide what you want your UX to be and then make your API implement your UX.
I'm following the Quick Start Guide, as I've just received my credentials. I went through the coblogin and user (consumer) creation successfully. For test purposes, I was able to search and list sites and infos.
When I try to invoke addSiteAccount1 using the user session token for the consumer that I create, I get an HTTP 200 response and no apparent error, no exceptions or messages. The JSON response is basically the same as the one listed in the API documentation page, however there's no ID I can use to list transactions. I'm using a real login/password account information on Chase (site ID 643).
By the way, if I use random strings for credentialFields[0].value (username) and credentialFields[1].value (password), I get the same JSON response.
Please help me clarify what is not working here.
addSiteAccount1 API will give you a response which should contain "siteAccountId" field this is the identifier for that particular user's Chase bank site.
This siteAccountId will have itemIDs which resembles different 'container'(in Yodlee terminology) like, all saving and checking accounts comes under bank container,while credit card comes under credit's container similarly loan and mortgages are other containers.
Now even under a specific container you might have multiple accounts for e.g., Chase Bank container you might have 1 saving's account and 1 checking account, for each there will be an itemAccountId available. This uniquely identifies that specific account and you can pass this itemAccountId (which you can get from getItemSummariesForSite API) in executeUserSearchRequest API to get the transactions belongs to this specific account.
For further help here is the link for the API flow which will give you an idea about how and when to use different APIs.
OK, I think I got it working, but maybe some documentation clarification is needed. Provided that all mandatory parameters in the addSiteAccount1 are present and contain no errors, the method call will be successful for a given consumer.
I then visited the getAllSiteAccounts method, which would show me all account aggregation for that user/consumer. I was able to see all accounts added, some had a message like "REFRESH_COMPLETE" and others would have "AUTH_FAILED". It seems that once one adds an account, the Yodlee robots will try to login and then synchronize the data for a given account. Makes sense?
I was only able to verify if the bank credentials were OK by calling another method.
Let's say a user accesses a resource and it maps to a handler foo().
In foo() I want to check if the user's session is valid.
For maximum decoupling (and for the sake of the example) I put the provided session ID into a message and push that into the queue VERIFY_SESSION where it is picked up by a subscribed worker.
The worker takes the session ID out of the message, checks the database, etc and then adds some data indicating the session is valid to the message before pushing it to VERIFIED_SESSIONS.
Question:
How do I get the information that the session is valid back into the worker that handles the user's connection?
If I subscribe all frontend workers to the queue VERIFIED_SESSIONS, there is no way of telling which worker will receive it.
All I can think of would be to basically implement RPC on top of the message queue, but that would defeat the purpose of having the queue to begin with.
What is the common pattern here?