+ result += "\n burst|look[|order] Show programmed burst message for order provided, current when missing.";
+ result += "\n";
+ result += "\n-------------------------------------------------------------------------------------- Advanced testing";
+ result += "\n";
+ result += "\n Burst mode only allows single interface interaction. For multiple interface";
+ result += "\n (realm) coordination, you could use the advanced test cases programming:";
+ result += "\n";
+ result += "\n";
+ result += "\n test|<id>|<command>[|parameters]";
+ result += "\n";
+ result += "\n Adds a new step to the test case with provided identifier. If provided identifier";
+ result += "\n is not registered yet, a new test case will be created with that value and the";
+ result += "\n step will be added as the first. For a specific 'id', the steps are stored in";
+ result += "\n order as they are programmed";
+ result += "\n";
+ result += "\n <id>: integer number, normally monotonically increased for each test case. Some external";
+ result += "\n script/procedure shall clone a test case template in order to build a collection";
+ result += "\n of independent and coherent test cases (normally same type) with different context";
+ result += "\n values (Session-Id, Subscriber-Id, etc.).";
+ result += "\n";
+ result += "\n <command>: commands to be executed for the test id provided. Each command programmed";
+ result += "\n constitutes a test case 'step', numbered from 1 to N.";
+ result += "\n";
+ result += "\n timeout|<msecs> Sets an asynchronous timer to restrict the maximum timeout";
+ result += "\n until last test step. Normally, this command is invoked";
+ result += "\n in the first step, anyway it measures the time from the";
+ result += "\n execution point whatever it is. The expiration will abort";
+ result += "\n the test if still running. One or more timeouts could be";
+ result += "\n programmed (not usual), but the more restrict will apply.";
+ result += "\n It is highly recommended to program a initial timeout step,";
+ result += "\n or the test case could be eternally in-progress.";
+ result += "\n";
+ result += "\n sendxml2e|<source_file>[|<step number>]";
+ result += "\n Sends xml source file (pathfile) to entity (it would be a";
+ result += "\n 'forward' event if it came through local server endpoint).";
+ result += "\n The step number should be provided for answers to indicate";
+ result += "\n the 'wait for request' corresponding step. If you miss this";
+ result += "\n reference, the sequence information (hop-by-hop, end-to-end)";
+ result += "\n will be sent as they are in the answer xml message (realize";
+ result += "\n the difficulty of predicting these information). Be sure to";
+ result += "\n refer to a 'wait for request' step. Conditions like 'regexp'";
+ result += "\n (as we will see later) are not verified.";
+ result += "\n";
+ result += "\n sendxml2c|<source_file>[|<step number>]";
+ result += "\n Sends xml source file (pathfile) to client (it would be a";
+ result += "\n 'forward' event if it came through remote server endpoint).";
+ result += "\n Same commented for 'sendxml2e' regarding the step number.";
+ result += "\n";
+ result += "\n delay|<msecs> Blocking step until the time lapse expires. Useful to give ";
+ result += "\n some cadence control and time schedule for a specific case.";
+ result += "\n wait<fe/fc>|<condition> Blocking step until condition is fulfilled. The message could";
+ result += "\n received from entity (waitfe) or from client (waitfc).";
+ result += "\n";
+ result += "\n wait<fe/fc>-regexp|<regexp>";
+ result += "\n Wait condition, from entity (waitfe-regexp) or client (waitfc-regexp)";
+ result += "\n to match the serialized xml content for received messages. CPU cost";
+ result += "\n is bigger than the former ones because the whole message must be";
+ result += "\n decoded and converted to xml instead of doing a direct hexadecimal";
+ result += "\n buffer search. The main advantage is the great flexibility to identify";
+ result += "\n any content with a regular expression.";
+ result += "\n";
+ result += "\n <condition>: Optional parameters which must be fulfilled to continue through the next step.";
+ result += "\n Any received message over diameter interfaces will be evaluated against the";
+ result += "\n corresponding test case starting from the current step until the first one";
+ result += "\n whose condition is fulfilled. If no condition is fulfilled the event will be";
+ result += "\n classified as 'uncovered' (normally a test case bad configuration, or perhaps";
+ result += "\n a real unexpected message).";
+
+ // TODO(***)
+// result += "\n The way to identify the test case, is through registered Session-Id values for";
+// result += "\n programmed requests. But this depends on the type of node. Acting as clients,";
+// result += "\n requests received have Session-Id values which are already registered with";
+// result += "\n one test case, causing an error if not found. Acting as servers, requests are";
+// result += "\n received over a diameter local server from a client which are generating that";
+// result += "\n Session-Id values. Then we know nothing about such values. The procedure in";
+// result += "\n this case is find out a test case not-started containing a condition which";
+// result += "\n comply with the incoming message, and reactivates it.";
+ // The other solution: register Session-Id values for answers send to client from a local diameter server.
+
+ result += "\n How to answer: a wait condition for a request will store the incoming message";
+ result += "\n which fulfills that condition. This message is useful together with the peer";
+ result += "\n connection source in a further send step configured with the corresponding";
+ result += "\n response. You could also insert a delay between wait and send steps to be";
+ result += "\n more realistic (processing time simulation in a specific ADML realm node).";
+ result += "\n Always, a response send step will get the needed information from the most";
+ result += "\n recent wait step finding in reverse order (note that some race conditions";
+ result += "\n could happen if your condition is not specific enough).";
+
+ result += "\n";
+ result += "\n Condition format:";
+ result += "\n";
+ result += "\n [code]|[bitR]|[ResultCode]|[sessionId]|[hopByHop]|[msisdn]|[imsi]|[serviceContextId]";
+ result += "\n";
+ result += "\n code: integer number";
+ result += "\n bitR: 1 (request), 0 (answer)";
+ result += "\n ResultCode: integer number";
+ result += "\n sessionId: string";
+ result += "\n hopByHop: integer number or request send step reference: #<step number>";
+ result += "\n";
+ result += "\n Using the hash reference, you would indicate a specific wait condition";
+ result += "\n for answers. The step number provided must correspond to any of the";
+ result += "\n previous send commands (sendxml2e/sendxml2c) configured for a request.";
+ result += "\n This 'hop-by-hop' variant eases the wait condition for answers in the";
+ result += "\n safest way.";
+ result += "\n";
+ result += "\n msisdn: string";
+ result += "\n imsi: string";
+ result += "\n serviceContextId: string";
+ result += "\n";
+ result += "\n Take into account these rules, useful in general:";
+ result += "\n";
+ result += "\n - Be as much specific as possible defining conditions to avoid ambiguity sending";
+ result += "\n messages out of context due to race conditions. Although you could program several";
+ result += "\n times similar conditions, some risky practices will throw a warning trace (if you";
+ result += "\n repeat the same condition within the same test case).";
+ result += "\n - Adding a ResultCode and/or HopByHop to the condition are only valid waiting answers.";
+ result += "\n - Requests hop-by-hop values must be different for all the test case requests.";
+ result += "\n RFC says that a hop by hop must be unique for a specific connection, something that";
+ result += "\n could be difficult to manage if we have multiple available connections from client";
+ result += "\n side endpoint (entity or local server), even if we would have only one connection but";
+ result += "\n several realm interfaces. It is enough to configure different hop-by-hop values within";
+ result += "\n each test case, because on reception, the Session-Id is used to identify that test case.";
+ result += "\n";
+ result += "\n";
+ result += "\n";
+ result += "\n";
+ result += "\n Programming example:";
+ result += "\n";
+ result += "\n Basic Rx/Gx scenary: PCEF (Gx) - PCRF - AF (Rx)";
+ result += "\n";
+ result += "\n test|1|timeout|5000 (step 1: whole time requirement is 5 seconds)";
+ result += "\n test|1|sendxml2e|CCR-I.xml (step 2: imagine this xml uses the Session-Id 'SGx')";
+ result += "\n test|1|waitfe|272|0|2001|SGx (step 3: waits the CCA for the CCR-I with Result-Code = DIAMETER_SUCCESS)";
+ result += "\n test|1|sendxml2e|AAR-flows.xml (step 4: imagine this xml uses the Session-Id 'SRx')";
+ result += "\n test|1|waitfe|265|0|2001|SRx (step 5: waits the AAA for the AAR-flows with Result-Code = DIAMETER_SUCCESS)";
+ result += "\n test|1|waitfe|258|1||SGx (step 6: waits the RAR (install policies) from the PCRF server)";
+ result += "\n test|1|sendxml2e|RAA-install.xml|6 (step 7: sends the response for the RAR)";
+ result += "\n test|1|sendxml2e|CCR-T.xml (step 8: termination of the Gx session, imagine this xml puts hop-by-hop 'H1')";
+ result += "\n test|1|waitfe|272|0|2001|SGx|H1 (step 9: waits the CCA for the CCR-T with Result-Code = DIAMETER_SUCCESS and hop-by-hop 'H1')";
+ result += "\n test|1|waitfe|258|1||SGx (step 10: waits the RAR (remove policies) from the PCRF server)";
+ result += "\n test|1|sendxml2e|RAA-remove.xml|10 (step 11: sends the response for the RAR)";
+ result += "\n";
+ result += "\n Notes: We added an additional condition in step 9: the hop-by-hop. When we program the corresponding";
+ result += "\n source request (CCR-T), we configured the value 'H1' for the hop-by-hop. This is an 'application";
+ result += "\n value' because the real hop-by-hop transported through the client connection is managed by the";
+ result += "\n diameter stack. But when returned, the transaction pool resolve the original value. This feature";
+ result += "\n is necessary to ease the implementation of certain diameter agents (proxies for example). In our";
+ result += "\n case, we could format the hop-by-hop values within the request templates with total freedom to";
+ result += "\n improve the programmed conditions.";
+ result += "\n";
+ result += "\n In the case of 'waiting for requests' is not such easy. Indeed, steps 6 and 10 will write a warning";
+ result += "\n because they are the same condition. We know that we are not going to have any problem because";
+ result += "\n such events are blocking-protected regarding logic-dependent messages (CCR-T), and race condition";
+ result += "\n is absolutely strange in this case.";
+ result += "\n";
+ result += "\n You could speed up the test case moving forward steps like 3 & 5, understood as non-strict requirements";
+ result += "\n to continue testing. Anyway, remember that test cases should be as real as possible, and that there";
+ result += "\n are many ways to increase the load rate as we will see in next section (test cases execution).";
+ result += "\n";
+ result += "\n Other simplifications: the steps 3, 5 and 9 can be replaced by";
+ result += "\n";
+ result += "\n test|1|waitfe||0|||#2";
+ result += "\n test|1|waitfe||0|||#4";
+ result += "\n test|1|waitfe||0|||#8";
+ result += "\n";
+ result += "\n which means that hop-by-hop must be retrieved from steps 2, 4 and 8 respectively,";
+ result += "\n and the expected message shall be an answer. Normally you will add other conditions,";
+ result += "\n for example a DIAMETER_SUCCESS result (adding 2001 as Result-Code).";
+ result += "\n";
+ result += "\nTest cases execution:";
+ result += "\n";
+ result += "\n";
+ result += "\n test|ttps|<amount> Starts/resume the provided number of test ticks per second (ttps). The ADML starts";
+ result += "\n with the event trigger system suspended, and this operation is neccessary to begin";
+ result += "\n those cases which need this time event (internal triggering). Some other test cases";
+ result += "\n could be started through external events (first test case event could be programmed";
+ result += "\n to wait specific message), but is not usual this external mode and neither usual to";
+ result += "\n mix triggering types. Normally, you will pause/stop new test launchs providing 0 as";
+ result += "\n ttps value, and also you could dynamically modify the load rate updating that value.";
+ result += "\n If a test case has N messages then 'ttps * N' will be the virtual number of messages";
+ result += "\n managed per second when no bottleneck exists.";
+ result += "\n";
+ result += "\n Provide 0 in order to stop the timer triggering.";
+ result += "\n";
+ result += "\n There timer manager resolution currently harcoded allows a maximum of ";
+ result += anna::functions::asString(1000/a_admlMinResolution); result += " events";
+ result += "\n per second. To reach greater rates ADML will join synchronously the needed number of";
+ result += "\n new time-triggered test cases per a single event, writting a warning-level trace to";
+ result += "\n advice about the risk of burst sendings and recommend launching multiple instances";
+ result += "\n to achieve such load with a lower rate per instance.";
+ result += "\n";
+ result += "\n test|ip-limit[|amount] In-progress limit of test cases. No new test cases will be launched over this value";
+ result += "\n (test Manager tick work will be ignored). Zero-value is equivalent to stop the clock.";
+ result += "\n tick, -1 is used to specify 'no limit' which is the default. If missing amount, the";
+ result += "\n limit and current amount of in-progress test cases will be shown.";
+ result += "\n";
+ result += "\n test|goto|<id> Updates current test pointer position.";
+ result += "\n";
+ result += "\n test|look[|id] Show programmed test case for id provided, current when missing. Test cases programmed";
+ result += "\n are not dumped on process context (too many information in general). When the test case";
+ result += "\n has been completed or initiated, it will contain context information acting as a report.";
+ result += "\n";
+ result += "\n test|report[|[yes]|no] Every time a test case is finished, its xml representation will be dump on a file under";
+ result += "\n the execution directory (or the one configured in process command-line 'tmDir') with";
+ result += "\n the name 'testcase.<id>.xml'. If repeat mode is active, new test case executions will";
+ result += "\n append its reports into the same file. This option is disabled by default to improve";
+ result += "\n performance (reducing IO). ADML process context will show test manager whole information";
+ result += "\n and test case reports will be written depending on this report option. Anyway, you could";
+ result += "\n use the 'look' operation to see the report.";
+ result += "\n";
+ result += "\n test|report-hex[|[yes]|no] Reports could include the diameter messages in hexadecimal format. Disabled by default.";
+ result += "\n";
+ result += "\n test|reset|<soft/hard>[|id] Reset the test case for id provided, all the tests when missing. It could be hard/soft:";
+ result += "\n - hard: you probably may need to stop the load rate before. This operation initializes";
+ result += "\n all test cases regardless their states.";
+ result += "\n - soft: only for finished cases (those with 'Success' or 'Failed' states). It does not";
+ result += "\n affect to test cases with 'InProgress' state.";
+ result += "\n";
+ result += "\n test|repeat[|[yes]|no] Restarts the whole programmed test list when finished, disabled by default (testing";
+ result += "\n time trigger system will enter suspended state until new ttps operation is received).";
+ result += "\n Test cases state & data will be reset (when achieved again), but general statistics";
+ result += "\n and counters will continue measuring until reset with 'collect' operation.";
+ result += "\n When the test cases pool has been processed (and this repeat option is disabled), you";
+ result += "\n could reactivate the testing by mean 'test|reset|soft' and then 'test|ttps|<value>'.";
+ result += "\n";
+ result += "\n test|clear Clears all the programmed test cases and stop testing (if in progress).";