Generate CEL User record on Blocks by default (checkbox option)

[fredcwbr]

Howdy ,

I'm using Astergazer to administer quite some IVRs, and in order to get all desired tracking , I'm generating quite a good ammount of UsegCEL in the process.
After looking in to the code, thoutgh about incorporating an option to the BLOCK so it could inherit a UserCEL that would be generated at TRANSLATE time from an option checkbox / textbox ( USEREVENTCODE , PARAMETERS ), in the various blocks .

So , whenever you check the "AUTOGENERATE USERCEL" , it would enable the textbox in that specific block to aggregate (like a combo) a USEREVENTBLOCK to it .,

This would associate that EVENT generation on the point, and would not pollute the script GUI with the blocks, considering that in that specific case , the EVENT is associated whith that block.,

In my need, It would suffice to generate a "[ENTRY|EXIT]_[BLOCK]{IDENTIFICACION | LABEL}" event , with an optional PARAMETER string., but thinking a little further, do believe that others would like to consider expanding this idea.

So, considering just this milestone of a supposed roadmap, could you give me the directions to code this in the better way possible, respecting your your structure?

Thanks in advance,

Frederico Wilhelms

[dmitriyborisenko]

Hi,

It sounds like an interesting idea.
Just a few notices. I think that the main purposes of this feature could be the gathering IVR historical statistic and scripts debugging. Thus we need:

• easily handle this possibility at the block, script and whole dialplan levels.
• be able to customize event body
• support different ways of data publication. If you have a lot of calls it might be undesirable to store all the data in the overloaded CEL table and you migth want to store it to some separate table (probably using FUNC_ODBC) or catch it via AMI by some 3-rd party application or even more, call some http API or execute a system command...

So my proposition is to implement some more flexible solution:

• add the checkbox properties "Before Block Execution" and "After Block Execution" to the application settings.
• add the properties "Before Block Command" and "After Block Command" to the application settings. Both of them are the text fields. The content of "Before Block Command" and "After Block Command" will be executed as native dialplan application accordingly before and after each block. If there are some predefined block-related wildcards are present inside of the content it will be replaced with a appropriate block or script property like "[blockLabel]", "[scriptName]" and so on. So we can perform any command like
  CELGenUserEvent(IvrEventBeforeBlock,uniqueid: ${UNIQUEID}, script: [scriptName], block: [blockLabel])
  or System(echo -e 'any text for script [scriptName]' >> /tmp/myLogFile) or just NoOp(Hello world!)...
• add the combobox properties "Before Block Execution" and "After Block Execution" to the script settings. Possible values: enabled/belong to parent(default)/disabled. If "belong to parent" is choosed then it will work according to the application settings.
• add the similar comboboxes to the each block settings. If "belong to the parent" is choosed then it will work according to the script settings.
• (optionally) add the same text fields "Before Block Command" and "After Block Command" to the script and block that might override the parent ones.

Therefore, the managing of this options does not need changes in the script structure, however it is still possible to add some thin customization by single "Custom" blocks.

With best regards,
Dmitriy Borisenko

[fredcwbr]

Howdy,

Right on the spot, it is for generating trace and historical information on the IVR for QA, process workflow and of course statisctical purposes. At that moment didn't even think of script debugging, which would certainly be a bonus.

Couldn't agree more about your concerns on the CEL , and when thinking about

supporting different ways of data publication.

• using external ODBC , ??SQL, AMI, AGI or whatever , would raise consideration on audit trails. If at any point there is any glitch on http(PUT or POST), or any of the assumed connector,
  -- it would have to handle the failure and either alert and/or halt the IVR ., .. ** would be a must.,
• additionaly, following your thoughts, suppose there would be a block to configure this "TRACE CONNECTOR" as a global on the dialplan.

Would that handling be done with an embedded macro after each "TRACE BLOCK" (if it can be called this way)?

When you say:

add the combobox properties "Before Block Execution" and "After Block Execution"

Would this be a code on the block.class so all blocks inherited from it? Did I get this right?

Best Regards,

Frederico C Wilhelms

[dmitriyborisenko]

Hi,

As far as I understand you want to hardcode some CEL function as before/after block notification command.
Actually I`m not proposing to implement the realization or support for different protocols such as http, AMI etc at this point. Instead of this I mean just the providing possibility to use anything instead or along with CEL. The command should not be hardcoded at all, It has to be fully customizable. The user should be able to write there whatever he wants. And he needs to use the block and script parameter values like name, label inside of this text.
It is simple just to parse this text then pass it to Asterisk to be executed there.
And it would not be hard for system administrator to write this custom command once for all application and change it for some script or some block if needed.

additionaly, following your thoughts, suppose there would be a block to configure this "TRACE CONNECTOR" as a global on the dialplan.
Would that handling be done with an embedded macro after each "TRACE BLOCK" (if it can be called this way)?

What do you mean by "TRACE CONNECTOR" and "TRACE BLOCK"?

"add the combobox properties "Before Block Execution" and "After Block Execution"
Would this be a code on the block.class so all blocks inherited from it? Did I get this right?"

Yes the command fields have to be declared in the base Block class.
And the TranslatorService must implement method(s) to handle it properly according to all related block/script/application settings.

Do you want to do it by yourself and make a pull request?
If there are any difficulties I can include it to my todo plans.

With best regards,
Dmitriy Borisenko

[fredcwbr]

Howdy,

Actually I`m not proposing to implement the realization or support for different protocols such as http, AMI etc at this point. Instead of this I mean just the providing possibility to use anything instead or along with CEL. The command should not be hardcoded at all, It has to be fully customizable. The user should be able to write there whatever he wants. And he needs to use the block and script parameter values like name, label inside of this text.

Didn't expressed myself correctly, can see why you thoutgh of a hard-code; actually, was thinking in an optional button (JS based template overlay ) to simplify the filling the field., I apologize if it suggested otherwise.

additionaly, following your thoughts, suppose there would be a block to configure this "TRACE CONNECTOR" as a global on the dialplan.
Would that handling be done with an embedded macro after each "TRACE BLOCK" (if it can be called this way)?

What do you mean by "TRACE CONNECTOR" and "TRACE BLOCK"?

Was under the impression that a new block "TRACE" would tie this, for the specific goal of generating these before/after events.

Do you want to do it by yourself and make a pull request?
If there are any difficulties I can include it to my todo plans.

Yes, was considering it really hard. Since I'm on a timeline, and quite sure this was not on your agenda for now, ...

Best regards,
Frederico Wilhelms