Scenario: Given CADD is greater than 0 and applicant confirmed as previous occupant at current address then match strength is IO
Given The Response contains "AC09>0"
And "Neaa01=0" or "NDac01=1"
When I fire the request
Then The Match strength should be "IO"
No and No.
This would ALMOST be a valid scenario in SpecFlow in terms of the parser would be able to handle it and you could run this test except that have used an or in the 2nd Given (the And). This really makes it two different scenarios.
Given The Response contains "AC09>0"
And "Neaa01=0"
When I fire the request
Then The Match strength should be "IO"
Given The Response contains "AC09>0"
And "NDac01=1"
When I fire the request
Then The Match strength should be "IO"
However as part of a BDD process this is very poor. Your aim should be to have a scenario that is in business langugae and you can imagine two non-technical people discussiing. I just don't ever see somebody saying "Neaa01=0" out loud.
And yet the description of the scenario you give is actually a far better example
Given CADD is greater than 0
and applicant confirmed as previous occupant at current address
then match strength is IO
If you could rephrase the Given CADD is greater than 0 then it would be quite neat.
Don't forget that SpecFlow's role is to turn the business language into something runnable, e.g.
[Given("applicant confirmed as previous occupant at current address")
public void ApplicantConfirmedAsPreviousOccupantAtCurrentAdddress()
{
Request.Neaa01=0;
}
Related
I'm scanning through the order list using the standard OrderSelect() function. Since there is a great function to get the current _Symbol for an order, I expected to find the equivalent for finding the timeframe (_Period). However, there is no such function.
Here's my code snippet.
...
for (int i=orderCount()-1; i>=0; i--) {
if (OrderSelect(i, SELECT_BY_POS, MODE_TRADES)) {
if (OrderMagicNumber()==magic && OrderSymbol()==_Symbol ) j++;
// Get the timeframe here
}
}
...
Q: How can I get the open order's timeframe given it's ticket number?
In other words, how can I roll my own OrderPeriod() or something like it?
There is no such function. Two approaches might be helpful here.
First and most reasonable is to have a unique magic number for each timeframe. This usually helps to avoid some unexpected behavior and errors. You can update the input magic number so that the timeframe is automatically added to it, if your input magic is 123 and timeframe is M5, the new magic number will be 1235 or something similar, and you will use this new magic when sending orders and checking whether a particular order is from your timeframe. Or both input magic and timeframe-dependent, if you need that.
Second approach is to create a comment for each order, and that comment should include data of the timeframe, e.g. "myRobot_5", and you parse the OrderComment() in order to get timeframe value. I doubt it makes sense as you'll have to do useless parsing of string many times per tick. Another problem here is that the comment can be usually changed by the broker, e.g. if stop loss or take profit is executed (and you need to analyze history), and if an order was partially closed.
One more way is to have instances of some structure of a class inherited from CObject and have CArrayObj or array of such instances. You will be able to add as much data as needed into such structures, and even change the timeframe when needed (e.g., you opened a deal at M5, you trail it at M5, it performs fine so you close part and virtually change the timeframe of such deale to M15 and trail it at M15 chart). That is probably the most convenient for complex systems, even though it requires to do some coding (do not forget to write down the list of existing deals into a file or deserialize somehow in OnDeinit() and then serialize back in OnInit() functions).
I have a project in which its activities and functions follows a sequential process, most of the time. But sometimes you need to "go back" your steps and rerun the previous functions.
I made a state diagram to see how complex it would be.
The first approach I thought was applying the State pattern but the number of states did not seem feasible. Then "I separated" and classified it functions in 6 processes. A grades traits each process what I imagined something like this:
TProcessXXX = class(TProcess)
private
{* atributos privados, etc.. *}
public
{* funciones y actividades *}
procedure DoActivity1;
procedure DoActivity2;
{* ... *}
function DoActivityN: TResultProcess;
end;
Most of the activities they of the each Process operate on the same class that encapsulates the data structure needed. And my intention is that each Process can notify has ended for another process then the next job.
The design I've seen is the Mediator pattern, and have a class that encapsulates the state diagram and "enable" to each process.
To coordinate among themselves I considered add methods to communicate with the coordinator/mediator class. Including:
function TProcess.RequestPermission: boolean;
procedure TProcess.NotifyFinishOperation(Result: TResultOperation);
In the process I designed them with some independence.
As for being not asking permission for each activity and for some need some redundant sequencing and ask again and again, I applied a "lock" that allows enable them.
TProcessXXX.PrepareToWork;
var req: boolean;
begin
req: = RequestPermission;
then begin if req
EnableActivitys
Work;
end;
end;
So far so good. My doubts began when from the Presentation layer invoke operations processes.
To get permission to invoke I have a indirection from the layer Presentation to the Mediator: Presentation -> TProcessXXX -> Mediator
And then we obtained permission another for each activity: Presentation -> TProcessXXX -> TDataStructure
When a process receives permission, captures for himself using TDataStructure. It takes over until the operation is completed. Meanwhile, other processes are "idle". And from the Presentation layer may be giving you request to operate needlessly.
I considered disabling controls, which is the most straightforward and easy. But then would have to be enabling and disabling all the time.
I ask: What alternatives do you recommend? Is there a pattern to work on the theme of "idle processes"?
EDIT:
I have studied alternatives such as Strategy and Visitor but I am not sure if they are the best option. And I admit that perhaps these 3 patterns (Mediator, Strategy, Visitor) do not dominate the 100%.
I forgot to clarify this. My apologies.
I would also add that if I deserve a negative vote, at least be kind enough to post a comment explaining why.
EDIT 2:
As recommended, I attached a link to a picture of the state diagram:
In the diagram you can see that there is a choise. Is designed so that at startup evaluates which was the last state reached and to continue from that point.
In this diagram I have separate activities in five processes: configuration, manage set, training, testing and recognition.
And I added one more, the sixth named initializer, which has the function to initialize the data structure with the data accessed from a database.
Each Process is a Collegue for the Mediator. The Mediator implements this state diagram and decides to process him "permission" to operate.
Your question isn't best formed so I'm not compleetly sure what are you trying to achieve. But I asume you want to implement some more complex code flow controll which is based on certain conditions.
If my asumption is correct you should check the Decision Tree pattern.
In Decision Tree pattern you have your work divided into multiple smaller steps(which is what yseems you are already trying to implement).
On the end of each step you check specific condition and then decide how to proceed based on that condition (either continue with next step, repeat current step or even jumpt to compleetly different step).
From your SO profile information I see you are computer engineering student so I can tell you that the usage of decision trees is usually discussed during the AI development classes in great depth becouse most complex AI algorithms actually depends on using Decision Tree pattern as it procidea great scalability.
So you might want to check your school books for the section that describes AI development.
The implementation guides (and most web resources I can find) describe the GS06 and ST02 Control Numbers as being unique only within the Interchange they are contained in. So when we build our GS and ST segments we just start the control numbers at 1 and increment as we add more Functional Groups and/or Transaction Sets. The ISA13 control numbers we generate are always unique.
The dilemma is when we receive a 999 acknowledgment; it does not include any reference to the ISA control number that it's responding to. So we have no way to find the correct originating Functional Group in our records.
This seems like a problem that anyone receiving functional acknowledgements would face, but clearly lots of systems and companies handle it, so what is the typical practice to reconcile 997s or 999s? I think we must be missing something in our reading of the guides.
GS06 and ST02 only have to be unique within the interchange, but if you use an ID that's truly unique for each one (not just within the message), then you can skip right to the proper transaction set or functional group, not just the right message.
I typically have GS start at 1 and increment the same way that you do, but the ST02 I keep unique (to the extent allowed by the 9 character limit).
GS06 is supposed to be globally unique, not only within the interchange. This is from X12-6
In order to provide sufficient discrimination for the acknowledgment
process to operate reliably and to ensure that audit trails are
unambiguous, the combination of Functional ID Code (GS01), Application
Sender's ID (GS02), Application Receiver's ID (GS03), and Functional
Group Control Numbers (GS06, GE02) shall by themselves be unique
within a reasonably extended time frame whose boundaries shall be
defined by trading partner agreement. Because at some point it may be
necessary to reuse a sequence of control numbers, the Functional Group
Date and Time may serve as an additional discriminant only to
differentiate functional group identity over the longest possible time
frame.
How a CAN Bus controller decides based on message identifier that this particular message belongs to it?Is it like the receiver already know that if identifier has suppose value 5 then its for me . And we program receiver to tell it that you should be interested in value 5 ?
The software in the CAN node must decide what message IDs it is interested in, based on the network specification which is usually some kind of document or other electronic representation of which messages contain what sorts of information. If a message arrives that is of no interest, it simply does not process it and the software returns to what it was doing just before the message arrived (assuming interrupt driven CAN handling).
Some CAN controllers (ie the part of the chip which does the CAN protocol transmission and reception) have message filtering which means that uninteresting messages can be dropped before they reach the software. Other controllers have message filtering which can be set to accept only a single message ID in a particular "message box", and these can be configured to accept the messages you are interested in. Again, other messages are dropped. Some controllers have both filters and message boxes.
At the CAN protocol level all nodes in a CAN network are equal and make a decision about whether to process a message or not. A "CAN controller" is a higher-level concept; it still needs to examine the message identifier like any other node.
Note that "processing" a message is different to the CAN protocol message check and acknowledgement. All nodes take part in that processing unless they're in "listen only" mode.
Update:
How you decide which message to process depends on what you are trying to do and the higher level protocol in use over CAN. In principle you mask out the ID bits that are relevant and then test them to see whether the message should be processed.
For example if you want to process all messages with 5 (binary 0101) in the low order four bits, your mask is 15 (binary 1111), you binary-and this with the received message ID, and then you compare the result with five.
For example:
(msg_id & 15) == 5
is a way of coding that test. Which bits you care about, and your implementation details depend on many other factors.
Specifically for PDU1 (Protocol Data Unit) messages, a destination address is specified (byte 3). If a device receives a message not addressed to it, it can simply ignore it. Addresses are assigned by various standards, or a manufacturer may assign them ad-hoc.
In the general case the CAN-ID (bytes 0-4) contains all the details about what kind of message it is, and devices can inspect particular fields to decide whether they care about the message. For example the transmission controller probably doesn't care about battery status messages, nor the fuel gauge about which doors are locked.
Was wondering if anyone out there can help.......
My company works in the travel industry and one of the product we provide is the function of buying a flight and hotel together.
One of the advantages of this is that sometimes a visitor can save on a hotel if they buy the package together.
What I want to be able to track is the following:
The hotel which has the saving on it (accomodation code); the saving that they will make; the price of the package that they will pay.
I am new to implementing but have been told by a colleague that I can use a context variable.
Would anyone be able to tell me how I should write this please?
Kind Regards
Yaser
Here is the document entry for Context Data Variables
For example, in the custom code section of the on-page code, within s_doPlugins or via some wrapper function that ultimately makes a s.t() or s.tl() call, you would have:
s.contextData['package.code'] = "accommodation code";
s.contextData['package.savings'] = "savings";
s.contextData['package.price'] = "price";
Then in the interface you can go to processing rules and map them to whatever props or eVars you want.
Having said that...processing rules are pretty basic at the moment, and to be honest, it's not really worth it IMO. Firstly, you have to get certified (take an exam and pass) to even access processing rules. It's not that big a deal, but it's IMO a pointless hoop to jump through (tip: if you are going to go ahead and take this step, be sure to study up on more than just processing rules. Despite the fact that the exam/certification is supposed to be about processing rules, there are several questions that have little to nothing to do with them)
2nd, context data doesn't show up in reports by themselves. You must assign the values to actual props/eVars/events through processing rules (or get ClientCare to use them in a vista rule, which is significantly more powerful than a processing rule, but costs lots of money)
3rd, the processing rules are pretty basic. Seriously, you're limited to just simple stuff like straight duping, concatenating values, etc.
4th, processing rules are limited in setting events, and won't let you set the products string. IOW, You can set a basic (counter) event, but not a numeric or currency event (an event with a custom value associated with it). Reason I mention this is because those price and savings values might be good as a numeric or currency event for calculated metrics. Well since you can't set an event as such via processing rules, you'd have to set the events in your page code anyways.
The only real benefit here is if you're simply looking to dupe them into a prop/eVar and that prop/eVar varies from report suite to report suite (which FYI, most people try to keep them consistent across report suites anyways, and people rarely repurpose them).
So if you are already being consistent across multiple report suites (or only have like 1 report suite in the first place), since you're already having to put some code on the site, there's no real incentive to just pop the values in the first place.
I guess the overall point here is that since the overall goal is to get the values into actual props, eVars and possibly events, and processing rules fail on a lot of levels, there's no compelling reason not to just pop them in the first place.