Henchway
Contributor
Joined 6 years ago
User Profile
User Widgets
Contributions
Re: Triggered Task with Accept: application/octet-stream header
Alright, got it working. Instead of sending back Content-Type: application/octet-stream, I had to lower-case to "content-type", the caller is now accepting the response. I was thinking that it's an issue with the server not being able to serve application/octet-stream at all, but i was mistaken. BR1.8KViews0likes0CommentsTriggered Task with Accept: application/octet-stream header
Hi all, currently i have the issue that I need to provide some data to an external import service (Jira Cloud Assets), which sends Accept: application/octet-stream in the headers, which is not accepted by Snaplogic. Snaplogic responds with 406 NOT ACCEPTABLE. Is there any way to allow that header? Best regards ThomasSolved1.8KViews0likes1CommentEnding document stream for some paths
Hello everyone, I have the need to let some stream paths end in “nothing”. Essentially I have a bunch of diff outputs that I will ignore, but eventually I will have to reduce the entire pipeline to a single output since it will be a triggered task. What would be the most elegant way of doing that without introducing too much overhead? Right now i would probably ‘Gate’ those outputs together and then simply ignore them, but is there a nicer option? Best regards ThomasSolved2.7KViews0likes2CommentsRe: Pagination with HTTP Client
Hi Matt, thank you very much, I couldn’t solve it with snap.in.totalCount , but snap.out.totalCount did the trick. For people searching this in the future, here is the configuration. Specifically this is used with the Workday REST API. Best regards Thomas4.3KViews4likes0CommentsPagination with HTTP Client
Hi, I’m not able to access the original document during pagination with the HTTP Client. This worked with the REST Client, but looks like it’s not possible any more. This is a needed feature when the API being called does not respond back with limit/offset/next url, but rather only responds with the total number of elements and a data array. Without accessing a previous document (e.g. $original.offset), pagination is not really possible without a rather odd workaround I found: Namely that I also send the offset as header, which I then access through $_debug in the pagination and thus increment it by the page size for the next call. (parseInt($_debug.request.headers.find(x => x.keys().pop() == 'X-OFFSET')['X-OFFSET']) + parseInt(_pageSize)).toString() Does anyone have a better solution for this (except reverting back to using the REST Get Snap)? Best regards ThomasSolved4.7KViews0likes2CommentsRe: Match operator: match object key with special characters
To elaborate a bit more, i now removed the XML namespaces in the document and then it works like a charm. E.g. in the following i’m checking three different attributes and two different cases: one where the data is delivered in an array and the other one in an object: match $Worker_Data.Personal_Data.Contact_Data.Email_Address_Data{ [..., { "Usage_Data": { "@Public": "1", "Type_Data": {"@Primary": "1", "Type_Reference": {"@Descriptor": "Work"}}}, Email_Address }, ...] => Email_Address, { "Usage_Data": { "@Public": "1", "Type_Data": {"@Primary": "1", "Type_Reference": {"@Descriptor": "Work"}}}, Email_Address } => Email_Address } When trying this with jsonPath and a ternary operator, it gets very convoluted: typeof $['wd:Worker_Data']['wd:Personal_Data']['wd:Contact_Data']['wd:Email_Address_Data'] == 'array' ? jsonPath($, "$['wd:Worker_Data']['wd:Personal_Data']['wd:Contact_Data']['wd:Email_Address_Data'][?(value['wd:Usage_Data']['@wd:Public'] == '1' && value['wd:Usage_Data']['wd:Type_Data']['@wd:Primary'] == '1' && value['wd:Usage_Data']['wd:Type_Data']['wd:Type_Reference']['@wd:Descriptor'] == 'Work')]['wd:Email_Address']").pop() : ($['wd:Worker_Data']['wd:Personal_Data']['wd:Contact_Data']['wd:Email_Address_Data']['wd:Usage_Data']['@wd:Public'] == '1' && $['wd:Worker_Data']['wd:Personal_Data']['wd:Contact_Data']['wd:Email_Address_Data']['wd:Usage_Data']['wd:Type_Data']['@wd:Primary'] == '1' && $['wd:Worker_Data']['wd:Personal_Data']['wd:Contact_Data']['wd:Email_Address_Data']['wd:Usage_Data']['wd:Type_Data']['wd:Type_Reference']['@wd:Descriptor'] == 'Work' ? $['wd:Worker_Data']['wd:Personal_Data']['wd:Contact_Data']['wd:Email_Address_Data']['wd:Email_Address'] : null ) Of course i wouldn’t want to remove the namespaces every time before i want to use the match operator, do you have a suggestion how to achieve with with match?2.9KViews0likes0CommentsRe: Match operator: match object key with special characters
Hi Supratim, thanks for the suggestion, that’s the way I’m currently doing it, however, I need to check not only ‘public’, but several other elements in different levels of the json as well as some conditional logic and that gets fairly tedious once it reaches a certain size. Here i would like to specifically solve this with the matcher and to know whether it’s possible to output a variable which includes special characters such as a colon. Best regards Thomas2.9KViews0likes0CommentsMatch operator: match object key with special characters
Hi all, I’m facing and issue where i would like to match some properties of an object within an array and then select a specific object key for the result. Since my source data is Workday XML, I have namespaces prepended to the object keys. In this match, i would like to retrieve the ‘wd:Email_Address’ element, but i believe that since i put that in quotes, it doesn’t realize that i want to declare it as variable. When i don’t do that, it will also not accept it due to the colon. Does anyone have a suggestion on how to deal with this? match $['wd:Worker_Data']['wd:Personal_Data']['wd:Contact_Data']['wd:Email_Address_Data'] { [..., { "wd:Usage_Data": { "@wd:Public": "1"}, 'wd:Email_Address' }, ...] => 'wd:Email_Address' } Here’s an exemplary data set that i’d like to match (the bulk before is omitted): "wd:Email_Address_Data": [ { "wd:Email_Address": "Thomas.scheibelhofer@kapsch.net", "wd:Usage_Data": { "@wd:Public": "1", "wd:Type_Data": { "@wd:Primary": "1", "wd:Type_Reference": { "@wd:Descriptor": "Work", "wd:ID": [ { "@wd:type": "WID", "$": "..." }, { "@wd:type": "Communication_Usage_Type_ID", "$": "WORK" } ] } } }, "wd:Email_Reference": { "@wd:Descriptor": "EMAIL_REFERENCE-3-7789", "wd:ID": [ { "@wd:type": "WID", "$": "..." }, { "@wd:type": "Email_ID", "$": "..." } ] }, "wd:ID": "..." }, { "wd:Email_Address": "test@test.test", "wd:Usage_Data": { "@wd:Public": "0", "wd:Type_Data": { "@wd:Primary": "1", "wd:Type_Reference": { "@wd:Descriptor": "Home", "wd:ID": [ { "@wd:type": "WID", "$": "..." }, { "@wd:type": "Communication_Usage_Type_ID", "$": "HOME" } ] } } }, "wd:Email_Reference": { "@wd:Descriptor": "...", "wd:ID": [ { "@wd:type": "WID", "$": "..." }, { "@wd:type": "Email_ID", "$": "..." } ] }, "wd:ID": "..." } ] ```json Best regards Thomas