BizTalk 2013 R2 - Decision Shape not following correct logic path - biztalk

Issue with an old Biz app (not designed or developed by myself).
Its orchestration receives a particular message, which is then fed into a Decision shape. If the below logic applies (as directly copy/pasted from the shapes first branch expression), it should go that route.
msg_inputCanonical.CRUD == "D" && msg_inputCanonical.DbTable == "Staff"
I can see it terminating however (by using the Orchestration Debugger) as it follows the Else branch and eventually hits a terminate shape.
I've checked the msg_inputCanonical to confirm the values being passed through (as below extracted from the Tracked Message part), and can see it matches the string condition in accordance with its mapping - CRUD = ChOp;
<DbTable>Staff</DbTable>
<ChOp>D</ChOp>
There's nothing else that I can see that's influencing this re-route, so can anyone think of any quirks that might be causing it?
Note: I've amended the WCF-SQL Stored Procedure that generates the msg_inputCanonical as prior to this it wasn't trimming any of the CRUD/DbTable values and had been leaving deadspace in.
There is also a map that uses ltrim/rtrim functoids on the ChOp property, but again - can't see what harm trimming an already trim'd field would do.
I have also tried replicating the logic in a dev environment, and it works as expected going down the correct branch when I'm passing the message through.

Related

Logic App using HTTP Action to access and GET Jira ticket

So I followed this answer and it works fine:
https://stackoverflow.com/a/74981947/20829088
Provided URL:
https://<YOUR_DOMAIN>.atlassian.net/rest/api/2/search?jql=project=<PROJECTID>&fields=issue,status,name&startAt=0&maxResults=8000
However, it take a lot of time. So, if I want the url to check for specific ticket depending on created time and type of ticket. For example
I want ticket that is created within 15 days and that are NOT a sub-task.
so I tried something like this.
.....&fields=issue,summary,issuetype&created>=-15d&hierarchylevel=0
I'm not sure of how it should be written I just tried this and it doesn't work.
Here is the request result in JSON:
It should be earthier [subtask=false] OR [hierarchylevel=0] OR [name=Task]
After reproducing from my end, I could able to achieve this using Condition connector of logic apps. I have initialized an array variable first and then tried to append each item that satisfies the condition. Below is the flow of my logic app.
and then I used Parse Json to retrieve the required values for condition comparision
You can use the below Code view to reproduce the same in your environment.
{"definition":{"$schema":"https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#","actions":{"For_each":{"actions":{"Compose":{"inputs":"#items('For_each')?['fields']?['created']","runAfter":{},"type":"Compose"},"Condition":{"actions":{"Append_to_array_variable":{"inputs":{"name":"Array","value":"#items('For_each')"},"runAfter":{},"type":"AppendToArrayVariable"}},"expression":{"or":[{"greaterOrEquals":["#formatDateTime(outputs('Compose'),'yyyy-MM-dd')","#formatDateTime(addDays(utcNow(),-15),'yyyy-MM-dd')"]},{"equals":["#items('For_each')?['fields']?['issuetype']?['subtask']",false]},{"equals":["#items('For_each')?['fields']?['issuetype']?['hierarchyLevel']",0]},{"equals":["#items('For_each')?['fields']?['status']?['statusCategory']?['name']","Task"]}]},"runAfter":{"Compose":["Succeeded"]},"type":"If"}},"foreach":"#body('Parse_JSON')?['issues']","runAfter":{"Parse_JSON":["Succeeded"]},"type":"Foreach"},"HTTP":{"inputs":{"authentication":{"password":"<API_KEY>","type":"Basic","username":"<USERNAME>"},"method":"GET","uri":"https://jira#<ProjectName>.atlassian.net/rest/api/2/search?jql=project=<ProjectID>"},"runAfter":{},"type":"Http"},"Initialize_variable":{"inputs":{"variables":[{"name":"Array","type":"array"}]},"runAfter":{"HTTP":["Succeeded"]},"type":"InitializeVariable"},"Parse_JSON":{"inputs":{"content":"#body('HTTP')","schema":{"properties":{"expand":{"type":"string"},"issues":{"items":{"properties":{"expand":{"type":"string"},"fields":{"properties":{"aggregateprogress":{"properties":{"progress":{"type":"integer"},"total":{"type":"integer"}},"type":"object"},"aggregatetimeestimate":{},"aggregatetimeoriginalestimate":{},"aggregatetimespent":{},"assignee":{},"components":{"type":"array"},"created":{"type":"string"},"creator":{"properties":{"accountId":{"type":"string"},"accountType":{"type":"string"},"active":{"type":"boolean"},"avatarUrls":{"properties":{"16x16":{"type":"string"},"24x24":{"type":"string"},"32x32":{"type":"string"},"48x48":{"type":"string"}},"type":"object"},"displayName":{"type":"string"},"emailAddress":{"type":"string"},"self":{"type":"string"},"timeZone":{"type":"string"}},"type":"object"},"customfield_10001":{},"customfield_10002":{},"customfield_10003":{},"customfield_10004":{},"customfield_10005":{},"customfield_10006":{},"customfield_10007":{},"customfield_10008":{},"customfield_10009":{},"customfield_10010":{},"customfield_10014":{},"customfield_10015":{},"customfield_10016":{},"customfield_10017":{"type":"string"},"customfield_10018":{"properties":{"hasEpicLinkFieldDependency":{"type":"boolean"},"nonEditableReason":{"properties":{"message":{"type":"string"},"reason":{"type":"string"}},"type":"object"},"showField":{"type":"boolean"}},"type":"object"},"customfield_10019":{"type":"string"},"customfield_10020":{},"customfield_10021":{},"customfield_10022":{},"customfield_10023":{},"customfield_10024":{},"customfield_10025":{},"customfield_10026":{},"customfield_10027":{},"customfield_10028":{},"customfield_10029":{},"customfield_10030":{},"customfield_10033":{},"description":{},"duedate":{},"environment":{},"fixVersions":{"type":"array"},"issuelinks":{"type":"array"},"issuetype":{"properties":{"avatarId":{"type":"integer"},"description":{"type":"string"},"entityId":{"type":"string"},"hierarchyLevel":{"type":"integer"},"iconUrl":{"type":"string"},"id":{"type":"string"},"name":{"type":"string"},"self":{"type":"string"},"subtask":{"type":"boolean"}},"type":"object"},"labels":{"type":"array"},"lastViewed":{},"priority":{"properties":{"iconUrl":{"type":"string"},"id":{"type":"string"},"name":{"type":"string"},"self":{"type":"string"}},"type":"object"},"progress":{"properties":{"progress":{"type":"integer"},"total":{"type":"integer"}},"type":"object"},"project":{"properties":{"avatarUrls":{"properties":{"16x16":{"type":"string"},"24x24":{"type":"string"},"32x32":{"type":"string"},"48x48":{"type":"string"}},"type":"object"},"id":{"type":"string"},"key":{"type":"string"},"name":{"type":"string"},"projectTypeKey":{"type":"string"},"self":{"type":"string"},"simplified":{"type":"boolean"}},"type":"object"},"reporter":{"properties":{"accountId":{"type":"string"},"accountType":{"type":"string"},"active":{"type":"boolean"},"avatarUrls":{"properties":{"16x16":{"type":"string"},"24x24":{"type":"string"},"32x32":{"type":"string"},"48x48":{"type":"string"}},"type":"object"},"displayName":{"type":"string"},"emailAddress":{"type":"string"},"self":{"type":"string"},"timeZone":{"type":"string"}},"type":"object"},"resolution":{},"resolutiondate":{},"security":{},"status":{"properties":{"description":{"type":"string"},"iconUrl":{"type":"string"},"id":{"type":"string"},"name":{"type":"string"},"self":{"type":"string"},"statusCategory":{"properties":{"colorName":{"type":"string"},"id":{"type":"integer"},"key":{"type":"string"},"name":{"type":"string"},"self":{"type":"string"}},"type":"object"}},"type":"object"},"statuscategorychangedate":{"type":"string"},"subtasks":{"type":"array"},"summary":{"type":"string"},"timeestimate":{},"timeoriginalestimate":{},"timespent":{},"updated":{"type":"string"},"versions":{"type":"array"},"votes":{"properties":{"hasVoted":{"type":"boolean"},"self":{"type":"string"},"votes":{"type":"integer"}},"type":"object"},"watches":{"properties":{"isWatching":{"type":"boolean"},"self":{"type":"string"},"watchCount":{"type":"integer"}},"type":"object"},"workratio":{"type":"integer"}},"type":"object"},"id":{"type":"string"},"key":{"type":"string"},"self":{"type":"string"}},"required":["expand","id","self","key","fields"],"type":"object"},"type":"array"},"maxResults":{"type":"integer"},"startAt":{"type":"integer"},"total":{"type":"integer"}},"type":"object"}},"runAfter":{"Initialize_variable":["Succeeded"]},"type":"ParseJson"}},"contentVersion":"1.0.0.0","outputs":{},"parameters":{},"triggers":{"manual":{"inputs":{"schema":{}},"kind":"Http","type":"Request"}}},"parameters":{}}

How am I sure that my process has a user interface?

When running a class which can be used interactively or silently by batch, I want to display a hourglass, only if in interactive mode.
I found the function xGlobal::clientKind() , read below, but not sure it is sufficient (can't batches also run on Client ?)
if (xGlobal::clientKind() == ClientType::Client)
startLengthyOperation();
// here do the process
if (xGlobal::clientKind() == ClientType::Client)
endLengthyOperation();
Do not bother to test client kind when using startLengthyOperation, the method does a sufficient test itself.
Testing should be like this:
if (clientKind() == ClientType::Client)
...
Don't use xGlobal::clientKind, use without qualification.
The ClientType has four values, matching what you see in "Online Users".
Batch can be called interactively in Basic/Periodic/Batch, but it should be rarely used.

Add custom text to AX 2012 drill-down links

I want to customize the standard drill-down functionality and add a text parameter to the drill-down URL. I will then parse and use the parameter in the SysStartUpCmdDrillDown or EventDrillDownPoller class like the solution provided by Jan B. Kjeldsen in this question.
The standard drill-down link is dynamics://Target/?DrillDown_RecID/ :
dynamics://0/?DrillDown_5637230378/
In previous versions of AX it was possible to modify the RecId to custom text and parse the text once the client is started:
dynamics://0/?DrillDown_0MenuItemName=PurchTable&FieldName=PurchId&FieldValue=P000044
Unfortunately, in AX 2012 the RecId is checked before the client is started and if it is not a valid int64, the drill-down event is not sent to the client. Since it is not possible to change the RecId to anything other than an integer, #Alex Kwitny suggested in the comments at that same question that you can add the custom text to the drill-down target like this:
dynamics://0MenuItemName=PurchTable/?DrillDown_5637230378/
The problem I experience with this is that the link now gets confused about which instance to start.
If the target is equal to the value in the System Admin -> system parameters -> Alerts ->Drill-down target, a client with the correct server instance is started. When I append the text with my custom text, it always starts the default instance(Which could be different from the instance I intended to start). While this is not ideal, I could work around this issue.
The bigger problem is that it now always starts a new session of the default instance, even if a client session is already started. As far as I can see I cannot write X++ code to solve this issue since the server instance is determined before any code in the client is executed.
My question is this - How can I add custom text to the drill-down link while preserving the way the client instance is started: If a client for the instance is already open, it should process the link in the open client, and not start up a new client of the default instance.
You should probably come up with another solution as mentioned in this post, but there could still be a way.
The URL has two objects that can be modified:
dynamics://[Drill-down target(str)]/?Drilldown_[Int64]
According to you, if you modify the [Drill-down target], then it launches AX using the default client config, and that is behavior that you don't want. If you have a matching [Drill-down target], it'll launch in the open client window, which is behavior I can't confirm, but I'll take it at face value and assume you're correct.
So that means the only thing you can modify in the URL is [int64]. This is actually a string that is converted to an int64 via str2int64(...), which in turn corresponds to a RecId. This is where it gets interesting.
This work all happens in \Classes\SysStartUpCmdDrillDown\infoRun.
Well, lucky for you the ranges for the objects are:
RecId - 0 to 9223372036854775807
Int64 - -9223372036854775808 to 9223372036854775807
You can call minRecId() and maxRecId() to confirm this.
So this means you have -9223372036854775808 to -1 numbers to work with by calling URLs in this range:
dynamics://0/?DrillDown_-1
to
dynamics://0/?DrillDown_-9223372036854775808
Then you would modify \Classes\SysStartUpCmdDrillDown\infoRun to look for negative numbers, and fork to your custom code.
HOW you decide to user these negative #'s is up to you. You can have the first n-digits be a table id or a look-up value for a custom table. You can't technically use a RecId as part of that negative number because in theory the RecId could get up that high (minus 1).

signalR message structure flags clarification?

I've read here about the structure of signalR's response message :
for example
For PersistentConnection
{"C":"B,2CE|K,C|L,2|M,0|I,0|J,0","M":["foo"]}
Where
Persistent Response:
C - cursor
M - Messages
T - Timeout (only if true) value is 1
D - Disconnect (only if true) value is 1
R - All Groups (Client groups should be reset to match this list exactly)
G - Groups added
g - Groups removed
Question #1
What's wrong with sending only the message part ? why do i need all the "C" information ? The client only needs the message. A message number #N is not dependent with message number #N-1 (AFAIK) -- so I dont see the reason for this "C" section. ( and I assume Im wrong by missing something here).
Question #2
Even so , how can I understand what the tokens means ? I didn't see in the manual the "K,L,I,J,2CE" tokens.
Where / How can I understand what they are saying ? What if I don't want the server to send that info but only the message ?
Open Source has an often over looked feature. You can simply download the source and take a look around. By simply searching in the source for the string "R" I was able to find some of the information you are looking for.
Answer #2:
These shorthand property names directly map to the JsonSerialization of objects in SignalR.
HubResponse
S - State
R - Result
I - Id
E - Error
T - StackTrace
PersistantResponse
L - LongPollDelay
D - Disconnect
T - TimedOut
G - GroupsToken
Some of the others are not found in the current code base, and since the issue your referring to is 7 months old I would guess they have been refactored out.
Answer #1:
The metadata is important to how SignalR operates. The double edged sword of frameworks is that we offload the domain or what it solves to the framework and its creators, and we implicitly agree to let them be the domain expert. Sometimes that makes it a bit of a black box to use, if you want to see what each of these properties are actually used for download the source and follow the code. If for some performance reason you feel the need to trim out some of the code around what you determine to be extraneous fork the code and give it a shot.

Google Analytics Realtime Sandbox Environment

I am looking for a way to setup a google analytics sandbox environment that will allow me
to test out my custom js code near real time.
My app will be using custom variables for advanced segmentation, and I would like to test out multiple scenarios quickly, as opposed to setting up a dummy GA account and wait for a whole day to confirm the test.
Thanks
Great question.
For GA, server updates occur every four hours, and after every sixth such update, the entire set is recalculated, which means a 24-hour lag from code change to reliable feedback. This delay also applies to most customizations to the GA Browser (e.g., "custom filters").
So if you are going to use GA as your web metrics system, and you expect to actually rely on those data then a test rig is essential.
For me, it's useful to group test systems for client-side analytics using two rubrics: (i) complete, self-contained (closed-loop) systems; or (ii) simpler automated data pulls from the production system (by "production system" here i mean GA's system, not the Site whose pages the GA code is tracking).
For the latter, just add this line to each page of your Site that contains the GA tracking code, just below '__trackPageview()':
pageTracker._setLocalRemoteServerMode();
That line will cause a copy of each transaction line to be logged to your server's activity log--so in essence, you get the data captured by GA in real-time That's all you need to do to capture the data; to parse it, you can use, for instance, any of the excellent open source web log analyzers like AWStats, or roll your own.
This is simple and reliable--but all it can do is tell you (in real-time) "does the analytics code i just implemented on pages served by my production server actually work?"
Usually, that's not good enough--you would rather know if your code will work before it's on your production server. To do that, you need to simulate the production environment and find a way to access in real-time the data GA collects.
This kind of test rig is a little more involved, but still not difficult.
In sum, it requires these steps:
host/serve the ga.js and the
tracking pixel locally;
log the __utm.gif requests (in the
GA data flow, each request
corresponds to one logged
transaction); and
parse the headers into some
convenient human-readable form.
If you want more detail than that (ie, a step-by-step implementation), here it is:
I. Hosting/Serving the GA Script (& automating updates
To do that, you can create a small shell script like this one to wget the latest ga.js version into your local directory (replacing the extant version it finds there).
#!/bin/sh
rm /My_Sites/sitename.com/analytics/ga.js
cd /My_Sites/sitename.com/analytics/
wget http://www.google-analytics.com/ga.js
chmod 644 /My_Sites/sitename.com/analytics/ga.js
cd ${OLDPWD}
exit 0;
(Thanks to AskApache.com, which provided the original motivation and config details to do this in a production context.)
II. Create __utm.gif file
This is just a transparent 1x1 pixel gif image, which you will place in Site directory (doesn't matter where, it just needs to match the location recited in your pages)
III. Log the __utm.gif Requests
For a testing protocol in which you are the source of the client-side activity (e.g., you want to verify the cross-browser fidelity of some event-tracking code you've added to a page on your Site, so you automate 5000 clicks on the button you just wired up,serving the page from your dev server set up for this purpose) it's probably simplest to just log the Request Headers, because it's in those headers that the GA script directs the client to gather various data from the DOM, from the location bar (url), and from prior http headers, and append them to a request for a resource on the GA server (__utm.gif, which is just a 1x1 transparent pixel).
For this type of protocol, i use the Firefox addon, LiveHTTPHeaders. You install it like any other Firefox addon, a few mouse clicks is all. Next, open it, and click the "Generator" tab. From this window, you can see the actual requests in real time. At the bottom of the window is a 'save' button to store the log. I find it easier to configure LiveHTTPHeaders to log only the __utm.gif requests; to do that, just click the 'Edit' tab and create a siimple filter to exclude everything except these particular gif images (using the check boxes on the right, and the large text box to the right).
Other kinds of test protocols require you to work from your Server Activity Logs; in that case just add this line to each page of your Site, just below __trackPageview():
pageTracker._setLocalRemoteServerMode();
IV. Parse those logged requests so you can actually read them
So now your log will contain individual transction lines, each one of which is a string appended to an HTTP Request for the GA tracking pixel. This string is just a concatenation of key-value pairs, each key begins with the letters "utm" (probably for "urchin tracker"). Each of these parameters corresponds to a variable that you see in the GA Dashboard (here's a complete list and description of them). This is all you need to know to build a parser. In more detail:
First, here's a sanitized __utm.gif request (the entries in your LiveHTTPHeaders log):
http://www.google-analytics.com/__utm.gif?utmwv=1&utmn=1669045322&utmcs=UTF-8&utmsr=1280x800&utmsc=24-bit&utmul=en-us&utmje=1&utmfl=10.0%20r45&utmcn=1&utmdt=Position%20Listings%20%7C%20Linden%20Lab&utmhn=lindenlab.hrmdirect.com&utmr=http://lindenlab.com/employment&utmp=/employment/openings.php?sort=da&&utmac=UA-XXXXXX-X&utmcc=__utma%3D87045125.1669045322.1274256051.1274256051.1274256051.1%3B%2B__utmb%3D87045125%3B%2B__utmc%3D87045125%3B%2B__utmz%3D87045125.1274256051.1.1.utmccn%3D(referral)%7Cutmcsr%3Dlindenlab.com%7Cutmcct%3D%2Femployment%7Cutmcmd%3Dreferral%3B%2B
This is my parser (in Python):
# regular expression module imported
import re
pattern = r'\&{1,2}'
pat_obj = re.compile(pattern)
# splitting the gif request on the '&' character
# (which GA originally used to concatenate each piece to build the request)
# (here, i've bound the __utm.gif to the variable by 'gfx')
gfx1 = pat_obj.split(gfx)
# create a look-up table to map a descriptive name to each gif request parameter
# (note, this isn't the entire list, which i've linked to above)
keys = "utmje utmsc utmsr utmac utmcc utmcn utmcr utmcs utmdt utme utmfl utmhn utmn utmp utmr utmul utmwv"
values = "java_enabled screen_color_depth screen_resolution account_string cookies campaign_session_new repeat_campaign_visit language_encoding page_title event_tracking_data flash_version host_name GIF_req_unique_id page_request referral_url browser_language gatc_version"
keys = keys.strip().split()
#create the look-up table
GIF_REQUEST_PARAMS = dict(zip(keys, values))
# parse each request parameter and map the parameter name to a descriptive name:
pattern = r'(utm\w{1,2})=(.*?)$'
pat_obj = re.compile(pattern)
for itm in gfx1 :
m = pat_obj.search(itm)
if m :
fmt = '{0:25} {1:10}'
print( fmt.format( GIF_REQUEST_PARAMS[m.group(1)], m.group(2) ) )
The result looks like this:
gatc_version              1         
GIF_req_unique_id         1669045322
language_encoding         UTF-8     
screen_resolution         1280x800  
screen_color_depth        24-bit    
browser_language          en-us     
java_enabled              1         
flash_version             10.0%20r45
campaign_session_new      1         
page_title                Position%20Listings%20%7C%20Linden%20Lab
host_name                 lindenlab.hrmdirect.com
referral_url              http://lindenlab.com/employment
page_request              /employment/openings.php?sort=da
account_string            UA-XXXXXX-X
cookies
To avoid making this longer still, i left out the cookies' value. They obviously require a separate parsing step, though it's virtually identical to the step i just showed. Again, each request represents a single transaction, so you can store them as you need to.

Resources