+ result += "\n Burst mode only allows single interface interaction. For multiple interface";
+ result += "\n (origin-host) 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. Check possible runtime exceptions when adding a";
+ result += "\n new step because those which fail, will be ignored/skipped during test case";
+ result += "\n programming giving an incomplete sequence invalid for the testing purpose.";
+ 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 Take into account that the xml message is encoded just on";
+ result += "\n call. The xml file is not longer needed neither interpreted";
+ result += "\n in case of modification, after calling this command.";
+ 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 In the case of requests, the step number is used to force the";
+ result += "\n copy of Session-Id value from the referred step.";
+ 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 A value of 0 could be used as a dummy step.";
+ result += "\n";
+ result += "\n sh-command|<script> External execution for script/executable via shell through a dedicated";
+ result += "\n thread, providing the command and parameters. You could use dynamic";
+ result += "\n variables ##<tag> to have more flexibility:";
+ result += "\n Test pool cycle id: "; result += SH_COMMAND_TAG_FOR_REPLACE__CYCLE_ID;
+ result += "\n Test case id: "; result += SH_COMMAND_TAG_FOR_REPLACE__TESTCASE_ID;
+ result += "\n Test step id: "; result += SH_COMMAND_TAG_FOR_REPLACE__TESTSTEP_ID;
+ result += "\n";
+ result += "\n For example, your command could be something like this:";
+ result += "\n insert_sql_"; result += SH_COMMAND_TAG_FOR_REPLACE__TESTCASE_ID; result += ".sh -db dbname --verbose";
+ result += "\n > /tmp/cycle-"; result += SH_COMMAND_TAG_FOR_REPLACE__CYCLE_ID;
+ result += ".testcase-"; result += SH_COMMAND_TAG_FOR_REPLACE__TESTCASE_ID;
+ result += ".teststep-"; result += SH_COMMAND_TAG_FOR_REPLACE__TESTSTEP_ID;
+ result += ".out";
+ result += "\n Try to redirect stdout and stderr to avoid ADML output contamination";
+ result += "\n with the possible outputs from the scripts. You could also put your";
+ result += "\n job in background although sh-command will return 0-value immediately.";
+ result += "\n";
+ result += "\n wait<fe/fc>-hex|<source_file>[|strict]";
+ result += "\n Wait condition, from entity (waitfe-hex) or client (waitfc-hex) to";
+ result += "\n match the hexadecimal representation for received messages against";
+ result += "\n source file (hex format). Fix mode must be enabled to avoid unexpected";
+ result += "\n matching behaviour. Specify 'strict' to use the hex content 'as is'.";
+ result += "\n If not, the hex content will be understood as whole message and then,";
+ result += "\n borders will be added (^<content>$) and sequence information bypassed";
+ result += "\n even for diameter answers.";
+ result += "\n";
+ result += "\n wait<fe/fc>-xml|<source_file>[|strict]";
+ result += "\n Wait condition from entity (waitfe-xml) or client (waitfc-xml) to";
+ result += "\n match the serialized xml content for received messages against";
+ result += "\n source file (xml representation). Fix mode must be enabled to avoid";
+ result += "\n unexpected matching behaviour. If you need a strict matching you";
+ result += "\n must add parameter 'strict', if not, regexp is built ignoring sequence";
+ result += "\n information (hop-by-hop-id=\"[0-9]+\" end-to-end-id=\"[0-9]+\") and";
+ result += "\n Origin-State-Id value.";
+ result += "\n All LF codes will be internally removed when comparison is executed";
+ result += "\n in order to ease xml content configuration.";
+ result += "\n";
+ 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 CPU cost is lower than former 'wait<fe/fc>-<xml|hex>' variants.";
+ 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 host 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]|[hopByHop]|[applicationId]|[sessionId]|[resultCode]|[msisdn]|[imsi]|[serviceContextId]";
+ result += "\n";
+ result += "\n code: integer number";
+ result += "\n bitR: 1 (request), 0 (answer)";
+ 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 applicationId: integer number";
+ result += "\n sessionId: string";
+ result += "\n resultCode: integer number";
+ 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 host 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|||SGx|2001 (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|||SRx|2001 (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|H1||SGx|2001 (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 The 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|next[|<sync-amount>] Forces the execution of the next test case(s) without waiting for test manager tick.";
+ result += "\n Provide an integer value for 'sync-amount' to send a burst synchronous amount of the";
+ result += "\n next programmed test cases (1 by default). This event works regardless the timer tick";
+ result += "\n function, but it is normally used with the test manager tick stopped.";
+ 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 'in-process' test case when missing.";
+ result += "\n Test cases reports are not dumped on process context (too many information in general).";
+ result += "\n The report contains context information in every moment: this operation acts as a snapshot.";
+ result += "\n";
+ result += "\n test|interact|amount|id Makes interactive a specific test case id. The amount is the margin of execution steps";
+ result += "\n to be done. Normally, we will execute 'test|interact|0|<test case id>', which means that";
+ result += "\n the test case is selected to be interactive, but no step is executed. Then you have to";
+ result += "\n interact with positive amounts (usually 1), executing the provided number of steps if";
+ result += "\n they are ready and fulfill the needed conditions. The value of 0, implies no execution";
+ result += "\n steps margin, which could be useful to 'freeze' a test in the middle of its execution.";
+ result += "\n You could also provide -1 to make it non-interactive resuming it from the current step.";
+ 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|repeats|<amount> Restarts the whole programmed test list when finished the amount number of times (repeats";
+ result += "\n forever if value -1 is provided). This is disabled by default (amount = 0): testing trigger";
+ result += "\n system will enter suspended state until new ttps operation is received and a soft reset has";
+ result += "\n been done before. Test cases state & data will be reset (when achieved again), but general";
+ result += "\n statistics and counters will continue measuring until reset with 'collect' operation.";
+ result += "\n";
+ result += "\n test|auto-reset|<soft|hard> When cycling, current test cases can be soft (default) or hard reset. If no timeout has";
+ result += "\n been configured for the test case, hard reset could prevent stuck on the next cycle for";
+ result += "\n those test cases still in progress.";
+ result += "\n";
+ result += "\n test|clear Clears all the programmed test cases and stop testing (if in progress).";
+ result += "\n";
+ result += "\n test|summary Test manager general report (number of test cases, counts by state, global configuration,";
+ result += "\n forced in-progress limitation, reports visibility, etc.). Be careful when you have reports";
+ result += "\n enabled because the programmed test cases dumps could be heavy (anyway you could enable the";
+ result += "\n dumps separately, for any of the possible states: Initialized, InProgress, Failed, Success).";
+ result += "\n";
+ result += "\n test|report|<initialized/in-progress/failed/success/[all]/none>[|[yes]|no]";
+ result += "\n";
+ result += "\n Enables/disables report generation for a certain test case state: initialized, in-progress,";
+ result += "\n failed or success (also 'all' and 'none' reserved words could be used). This applies to report";
+ result += "\n summary (former described operation) and automatic dumps during testing where only failed or";
+ result += "\n successful states will appear: every time a test case is finished its xml representation will";
+ result += "\n be dump on a file under the execution directory (or the one configured in process command-line";
+ result += "\n 'tmDir') with the name:";
+ result += "\n";
+ result += "\n 'cycle-<cycle id>.testcase-<test case id>.xml'.";
+ result += "\n";
+ result += "\n By default, all the states are disabled to avoid IO overload. In most of cases not all the";
+ result += "\n tests are going to fail then you could enable only such failed dumps. Anyway you could set";
+ result += "\n the reports visibility to fit your needs in a given situation.";
+ 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";
+ result += "\n------------------------------------------------------------------------------------- Dynamic procedure";
+ result += "\n";
+ result += "\ndynamic[|args] This launch an internal operation implemented in 'Procedure' class.";
+ result += "\n Its default implementation does nothing, but you could create a dynamic";
+ result += "\n library 'libanna_launcherDynamic.so' and replace the one in this project.";
+ result += "\n One interesting application consists in the use of the diameter API and";
+ result += "\n event operation to create a set of libraries as the testing framework.";
+ result += "\n To execute each test case, the ADML process would be executed with a";
+ result += "\n specific library path. But the main use would be the stress programming";
+ result += "\n to achieve a great amount of cloned (even mixed) tests without using";
+ result += "\n the management operation interface by mean http or signals: a single";
+ result += "\n call to 'dynamic' would be enough to start a cascade of internally";
+ result += "\n implemented operations.";
+ result += "\n This operation accepts a generic string argument (piped or not, as you";
+ result += "\n desire and depending on your procedure implementation).";
+ result += "\n";
+ result += "\n This operation requires advanced programming and knowlegde of ANNA Diameter";
+ result += "\n stack and testing framework, to take advantage of all the possibilities.";
+ result += "\n";
+ result += "\n";
+ result += "\n";
+ result += "\nUSING OPERATIONS INTERFACE";