Diagnosing an issue with a BizTalk app where part of it's logic doesn't seem to be triggering.
Currently it's designed to use a Decision Shape to filter on 2 values from a specific message.
One of those values is the word 'staff' in lower case, whereas the map that constructs the message uses a string functoid to populate the value as 'Staff' (sentence case).
I'd test this to see if it's the cause, but we don't currently have a test environment, and there's about 8 apps that this is a dependency on, so I'd need to go through a convoluted process of taking them all offline and deploying the small fix at a gamble.
On that basis, would anyone know; Is BizTalk Decide Shape Expression logic case sensitive?
Yes, the decide shape is case sensitive.
I tested with a rule
Message(FILE.ReceivedFileName) == "D:\\in\\YES.xml"
I dropped through a files YES.xml, yes.xml and YES.XML, and only the YES.xml went through the Rule branch, the other files went through the Else.
This is probably due to C# being case sensitive, see Is there a C# case insensitive equals operator?
Related
I have 2 questions on the case recorder.
1- I am not sure how to restart an optimizaiton from where the recorder left off. I can read in the case reader sql file etc but can not see how this can be fed into the problem() to restart.
2- this question is maybe due to my lack of knowledge in python but how can one access to the iteration number from within an openmdao component (one way is to read the sql file that is constantly being updated but there should be a more efficient way.)
You can re-load a case back via the load_case method on the problem.
See the docs for it here.
Im not completely sure what you mean by access the iteration count, but if you just want to know the number of times your components are called you can add a counter to them yourself.
There is not a programatic API for accessing the iteration count in OpenMDAO as of version 2.3
I have a doubt about about whether I should consider a certain type of test functional or contract.
Let's say I have an API like /getToolType, that accepts a {object" "myObject"} as input, and returns at type in the form {type: "[a-z]+"}
It was agreed between client and server that the types returned will match a set of strings, let's say [hammer|knife|screwdriver], so the consumer decided to parse them in an enum, with a fallback value when the returned type is unknown.
Should the consumer include a test case for each type(hammer, knife, screwdriver) to ensure the producer is still following the agreement that it will always return , for instance , the lowercase string "hammer" when /getToolType is called with an hammer object?
Or would you consider such a test case as functional? And why?
IMO the short answer is 'no'.
Contract testing is more interested in structure, if we start boundary testing the API we move into functional test territory, which is best done in the provider code base. You can use a matcher to ensure only one of those three values is returned, this should ensure the Provider build can't return other values.
I would echo #J_A_X's comments - there is no right or wrong answer, just be wary of testing all permutations of input/output data.
Great question. Short answer: there's no right or wrong way, just how you want to do it.
Longer answer:
The point of Pact (and contract testing) is to test specific scenarios and making sure that they match up. You could simply, in your contract, create a regex that allows any string type for those enums, or maybe null, but only if your consumer simply doesn't care about that value. For instance, if the tool type had a brand, I wouldn't care about the brand, just that it's returned back as a string since I just display the brand verbatim on the consumer (front-end).
However, if it was up to me, from what I understand of your scenario, it seems like the tool type is actually pretty important considering the endpoint it's hitting, hence I would probably have specific tests and contracts for each enum to make sure that those particular scenarios on my consumer are valid (I call X with something and I expect Y to have tool type Z).
Both of these solutions are valid, what it comes down to is this: Do you think the specific tool type is important to the consumer? If it is, create contracts specific to it, if not, then just create a generic contract.
Hope that helps.
The proper state is that consumer consumes hammer, knife, and screwdriver, c=(hammer,knife,screwdriver) for short while producer produces hammer, knife, and screwdriver, p=(hammer,knife,screwdriver).
There are four regression scenarios:
c=(hammer,knife,screwdriver,sword), p=(hammer,knife,screwdriver)
c=(hammer,knife,screwdriver), p=(hammer,knife,screwdriver,sword)
c=(hammer,knife,screwdriver), p=(hammer,knife)
c=(hammer,knife), p=(hammer,knife,screwdriver)
1 and 3 break the contract in a very soft way.
In the 1st scenario, the customer declared a new type that is not (yet) supported by the producer.
In the 3rd scenario, the producer stops supporting a type.
The gravity of scenarios may of course wary, as something I consider soft regression, might be in a certain service in a business-critical process.
However, if it is critical then there is a significant motivation to cover it with a dedicated test case.
2nd and 4th scenarios are more severe, in both cases, the consumer may end up in an error, e.g. might be not able to deserialize the data.
Having a test case for each type should detect scenario 3 and 4.
In the 1st scenario, it may trigger the developer to create an extra test case that will fail on the producer site.
However, the test cases are helpless against the 2nd scenario.
So despite the relatively high cost, this strategy does not provide us with full test coverage.
Having one test case with a regex covering all valid types (i.e. hammer|knife|screwdriver) should be a strong trigger for the consumer developer to redesign the test case in 1st and 4th scenario.
Once the regex is adjusted to new consumer capabilities it can detect scenario 4 with probability p=1/3 (i.e. the test will fail if the producer selected screwdriver as sample value).
Even without regex adjustment, it will detect the 3rd scenario with p=1/3.
This strategy is helpless against the 1st and 2nd scenario.
However, on top of the regex, we can do more.
Namely, we can design the producer test case with random data.
Assuming that the type in question is defined as follows:
enum Tool {hammer,knife,screwdriver}
we can render the test data with:
responseBody = Arranger.some(Tool.class);
This piece of code uses test-arranger, but there are other libraries that can do the same as well.
It selects one of the valid enum values.
Each time it can be a different one.
What does it change?
Now we can detect the 2nd scenario and after regex adjustment the 4th one.
So it covers the most severe scenarios.
There is also a drawback to consider.
The producer test is nondeterministic, depending on the drawn value it can either succeed or fail which is considered to be an antipattern.
When some tests sometimes fail despite the tested code being correct, people start to ignore the results of the tests.
Please note that producer test case with random data is not the case, it is in fact the opposite.
It can sometimes succeed despite the tested code is not correct.
It still is far from perfect, but it is an interesting tradeoff as it is the first strategy that managed to address the very severe 2nd scenario.
My recommendation is to use the producer test case with random data supported with a regex on the customer side.
Nonetheless, there is no perfect solution, and you should always consider what is important for your services.
Specifically, if the consumer can safely ignore unknown values, the recommended approach might be not a perfect fit.
I would like to have pre-emption calls in Asterisk. I think there is no Asterisk support for this feature so i'm trying to implement it following a simliar algorithm like the one showed in this thread: Asterisk - Pre-emption calls
So I'm having problems in this step:
check if B in call with lower priority caller( ASTDB or REALTIME or fastagi script).
I know how to check if B is in a call using for example DEVICE_STATE(device) cmd, but i can't achieve to know who is the other caller in order to see his priority.
So, How can I know if one users is in a call and who is the other caller inside this call?
Thanks a lot.
You can read variables of any channel using
SHARED(varname[,channel])
-= Info about function 'SHARED' =-
[Synopsis]
Gets or sets the shared variable specified.
[Description]
Implements a shared variable area, in which you may share variables between
channels.
The variables used in this space are separate from the general namespace
of the channel and thus ${SHARED(foo)} and ${foo} represent two completely
different variables, despite sharing the same name.
Finally, realize that there is an inherent race between channels operating
at the same time, fiddling with each others' internal variables, which is
why this special variable namespace exists; it is to remind you that variables
in the SHARED namespace may change at any time, without warning. You should
therefore take special care to ensure that when using the SHARED namespace,
you retrieve the variable and store it in a regular channel variable before
using it in a set of calculations (or you might be surprised by the
result).
Sure you have set variables first.
You can set in variables or in ASTDB name of current speaking channel using in-call macro
General complexity of any solution like you want is above average, need person with at least 1-2 year of extensive experience with *.
I am currently implementing an EDI solution in BizTalk Server 2010.
This is the scenario:
BizTalk is responsible for the correct message routing between a X.400 mailbox and the customer's ERP software. It is also used to put information about the exchanged message into a SharePoint site using the SharePoint webservices.
I am using Role Links and the BizTalk party management to apply the correct settings (send ports, password in UNB6 segment, etc.).
Now I have the following question:
When I try to fetch an outgoing INVOIC message from the customer's ERP system, extract the relevant information in an orchestration and write it into the SharePoint site, the receive port using the EDI receive pipeline gets suspended with the following error message:
An output message of the component "EDI disassembler" in receive pipeline
"**********.Pipelines.FileNamePromotionEDIReceivePipeline, **********.Pipelines,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=****************" is suspended
due to the following error:
Error: 1 (Miscellaneous error)
33: Invalid occurence outside message, package or group.
The sequence number of the suspended message is 1.
This happens because the message uses a CR and LF as suffix after each segment delimiter. Now I could add the ASCII-hex-codes for CR and LF to the "EfactDelimiters" setting of the pipeline, but the problem is that there are other messages without the CR and LF, which then could not be received using the same pipeline. By the way, when I fetch one of those messages without CR and LF using the pipeline also without CR and LF set as delimiters, the receive port also gets suspended, this time with an error message resulting from the usage of dots instead of commas as decimal separator (although I have enabled the option "UseDotAsDecimalSeparator" in the pipeline). Again, only changing the EfactDelimiters helps.
I thought that the "Character set and separators" page in the party agreement was supposed to make exactly that possible: To set the delimiters individually for each business party. But the changes I make in these settings seem to have no effect whatsoever. I set the "UNA6 Suffix" to "CR LF" and the "Decimal Notation (UNA3)" to ".(Decimal)", restart the host instance... same problem.
Can anyone help?
I never used biztalk, but I know my EDIFACT, and as far as I know, those messages containing CR/LF are syntactically wrong. The UNA6 Suffix seems to be an addition by Microsoft, as I can find no trace of it in the official documents on EDIFACT at UNECE.
Normally, the chars you want to use as special chars in an EDIFACT message are set by the special (optinal) UNA segment, which always comes first. When you write, you set the separators / delimiters, I don't really know, what you mean by that, as it could refer either to setting the options for the created message (what delimiters are used in the message), setting the delimiters used for parsing by the receiving program, or it could refer to the chars that are printed in the UNA segment.
Know, in the UNA segment, there is no way that I know of, to indicate the use of any UNA6 suffix (as stated quite explicitly in the documents, the UNA segment has to be exactly 9 characters of length, see 8.3 Interchange formatting rules). That leads me to the conclusion, that you set the options for the created messages. I would not advise to use a UNA6 suffix, if you can avoid it. It might be nice for humans to read the message, but it does not belong there and is not useful for the machine to read.
If the receiving program has no option to allow optional occurrence of CR/LF, and you can not avoid a mix of those to kind of messages, I see no other way for you other than somehow insert a small program that gets rid of the CR/LF.
The most important principle is of course, to make the sending and the receiving program talk in the same syntax, otherwise it can't work. The same thing goes for the problem with the decimal separator. As of Syntax rules, 10.1, either the comma or the dot is allowed, which is a quite loose definition. If you want to be on the save side, send an UNA segment, specifying which one you use, and then only use that one.
I'm not really sure, how much this helps you with the specific problem, as it might be a thing that's only a question on how to configure biztalk, but I thing some background information should be useful.
So we can use isObservable to work with some systems but I wonder If we can make tham show staps or do something like that. Is that possible?
I'm supposing that you are actually referring to the Observable and Controllable commands which are part of the DynamicSystems package.
Some Maple routines have so-called userinfo messages, which are optionally displayed and which can show partial steps. Those would typically be enabled with a call like infolevel[DynamicSystems]:=6 where 6 is the highest level of detail. With a lower value less detail might be displayed. Unfortunately, these particular DynamicSystems routines don't seem to have any userinfo messages in them. So this won't help directly in your case.
Sometimes one package calls another. The routine LinearAlgebra:-Rank is called, at some point, when Controllable is called. I'm guessing that you don't wish to see userinfo messages in Rank, which would be enabled by issuing infolevel[LinearAlgebra]:=n for some n between 1 and 6.
An alternative is to set printlevel high. But doing so will make all Maple internal calls also be verbose. The resulting output of setting, say, printlevel:=20 is overwhelming. I doubt that you'd find this approach useful.
Another alternative is to set certain routines as option trace. Sometimes doing so entails knowing the names of the appropriate internal routines. And this is made more complicated by the fact that not all non-exported module locals are visible by default. You could try first issuing the call, trace(DynamicSystems::ControllableSS): before invoking Controllable on your system. That shows some intermediary results, but those might not make much sense to you unless you know what source lines are generating those results. You can see the source by issuing the command, showstat(DynamicSystems::ControllableSS);
Here's an example,
restart:
with( DynamicSystems ):
aSys := StateSpace( <<1,2>|<3,4>>, <<2,3>>, <<1,0>|<0,1>>, <<0,0>> ):
aSys:-a, aSys:-b, aSys:-c:
trace(DynamicSystems::ControllableSS):
Controllable( aSys );
showstat(DynamicSystems::ControllableSS);
By looking at the source of the ControllableSS routine, you can deduce that it calls DynamicSystems:-StaircaseTransformation when the staircase method is specified. So here too you could issue showstat(DynamicSystems::StaircaseTransformation) to see the source of that internal (local) routine. Or you could trace that routine as well.
As a general rule, you can refer to exports of a module or package using the :- notation. And you can pass such names to trace and showstat using the :: notation instead of :-, unless you have first set kernelopts(opaquemodules=false). If an inner submodule member has more than one :- in its name then you'd have to use round-bracket delimiters to refer to it with the :: syntax. Sorry, that that's not so easy to express.