Monitor BCMS Skill renders JSON mess

[jjschwarz]

The monitor bcms skill command seems to dump all of the output as a single record in JSON format. Is this due to the formatting of the output, or something internal in the JSON parser?

[53hornet]

As far as I'm aware, most monitor commands are intended to be watched in interactive terminals. These commands are not supported by the OSSI protocol (and by extension Angelshark) in the same way they are in other terms. For example, if you start an OSSI terminal in a SAT session, and provide monitor bcms skill 1, you'll get one record of output and the command terminates. Angelshark just collects this single row of data and transforms it into JSON. If you use a VT220 or 513 terminal, you will get a live update with routinely refreshed data.

This is the same reason that monitor bcms skill XX isn't allowed in GEDI in ASA, only in emulation (GEDI uses OSSI but emulation uses 513). If you want routine refreshes, one option would be scheduling subsequent runs of this command and refreshing a view somewhere with the output data.

If I'm misreading your question lemme know and I'll try to reword or investigate further.

[jjschwarz]

I agree that watching them update is the intended goal, however due to a lack of options in the Avaya the monitor bcms skill command is the only way I am aware of to see who is currently logged into a queue. In our case that works as a single pass, but the output is a bit odd. I think the best idea is for me to scrape out just the fields for extension which appear to be in the format 000d03xx like this: [ { "acms": ["CM01"], "fields": ["000d0301","000d0302","000d0303","000d0304","000d0305","000d0306","000d0307","000d0308","000d0309","000d030a","000d030b","000d030c","000d030d","000d030e","000d030f","000d0311","000d0312","000d0313","000d0314","000d0315","000d0316","000d0317","000d0318","000d0319"], "command": "monitor bcms skill 1" } ]

The result is still a single line, but we can probably transform that into something useful, unless you have any other suggestions?

I am assuming that the field name can not be a wildcard as well, so no "000d03*" or "000d303.." type of field names?

On Jun 8, 2022, at 2:12 PM, Adam Carpenter @.***> wrote:

As far as I'm aware, most monitor commands are intended to be watched in interactive terminals. These commands are not supported by the OSSI protocol (and by extension Angelshark) in the same way they are in other terms. For example, if you start an OSSI terminal in a SAT session, and provide monitor bcms skill 1, you'll get one record of output and the command terminates. Angelshark just collects this single row of data and transforms it into JSON. If you use a VT220 or 513 terminal, you will get a live update with routinely refreshed data.

This is the same reason that monitor bcms skill XX isn't allowed in GEDI in ASA, only in emulation (GEDI uses OSSI but emulation uses 513). If you want routine refreshes, one option would be scheduling subsequent runs of this command and refreshing a view somewhere with the output data.

If I'm misreading your question lemme know and I'll try to reword or investigate further.

— Reply to this email directly, view it on GitHub https://github.com/adpllc/altruistic-angelshark/issues/11#issuecomment-1150236836, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIBX4OUUVOXP224XRXNOQLVODO77ANCNFSM5YHED2SA. You are receiving this because you authored the thread.

[53hornet]

If you want to see agents logged into a queue, maybe another option would be list agent staffed or list agent staffed skill XX? Would that help with this request? That will dump multiple rows of agents that you could manipulate or count programmatically.

Angelshark doesn't rearrange the data e.g. with field names or key-value pairs. For that, yes I would recommend transforming the output into the format you're interested in.

Using the field filters is a great way to just get what you want out of it. I do not believe OSSI supports wildcard fields. To see what your options are for fields there's always the manual terminal (angelsharkcli man), which outputs this:

cmonitor bcms skill BCMS SPLIT (AGENT) STATUS 0002ff00 Split: 3 Display Only 0004ff00 Date: 24 Display Only 0003ff00 Split Name: 15 Display Only 0005ff00 Calls Waiting: 5 Display Only 07d1ff00 Acceptable Service Level: 4 Display Only 0006ff00 Oldest Call: 7 Display Only 07d2ff00 % Within Service Level: 4 Display Only 0007ff00 Staffed: 3 Display Only 0008ff00 Avail: 3 Display Only 0009ff00 ACD: 3 Display Only 000aff00 ACW: 3 Display Only 3e81ff00 AUX: 3 Display Only 000bff00 Extn Calls: 3 Display Only 000cff00 Other: 3 Display Only ...

[jjschwarz]

We are using the older BCMS setup where the agentID is just the extension, so those reports come out empty for us.

I was using the anglesharkcli man to find the pattern earlier...just unfortunately every agent has a different field for each column.

Easy enough to manipulate on the back end, just making sure that I wasn't missing anything.

On Jun 8, 2022, at 2:57 PM, Adam Carpenter @.***> wrote:

If you want to see agents logged into a queue, maybe another option would be list agent staffed or list agent staffed skill XX? Would that help with this request? That will dump multiple rows of agents that you could manipulate or count programmatically.

Angelshark doesn't rearrange the data e.g. with field names or key-value pairs. For that, yes I would recommend transforming the output into the format you're interested in.

Using the field filters is a great way to just get what you want out of it. I do not believe OSSI supports wildcard fields. To see what your options are for fields there's always the manual terminal (angelsharkcli man), which outputs this:

cmonitor bcms skill BCMS SPLIT (AGENT) STATUS 0002ff00 Split: 3 Display Only 0004ff00 Date: 24 Display Only 0003ff00 Split Name: 15 Display Only 0005ff00 Calls Waiting: 5 Display Only 07d1ff00 Acceptable Service Level: 4 Display Only 0006ff00 Oldest Call: 7 Display Only 07d2ff00 % Within Service Level: 4 Display Only 0007ff00 Staffed: 3 Display Only 0008ff00 Avail: 3 Display Only 0009ff00 ACD: 3 Display Only 000aff00 ACW: 3 Display Only 3e81ff00 AUX: 3 Display Only 000bff00 Extn Calls: 3 Display Only 000cff00 Other: 3 Display Only ...

— Reply to this email directly, view it on GitHub https://github.com/adpllc/altruistic-angelshark/issues/11#issuecomment-1150282217, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIBX4L2GZY3NCYBMMVFYUTVODUI5ANCNFSM5YHED2SA. You are receiving this because you authored the thread.

[53hornet]

Ahh I hadn't even thought of that possibility. Yes, the really wide commands where multiple entries/records are displayed horizontally are a real pain (see: display capacity). Only saving grace is I think on a single Avaya version you can count on the fields being in the same order for each command run. That lets you index that array reliably, at least until an upgrade may change the field addresses. Let me know if you have any follow-up questions and thanks for the conversation.

[jjschwarz]

I think we managed to cover it all

Thank you for the feedback!

On Jun 8, 2022, at 3:12 PM, Adam Carpenter @.***> wrote:

Ahh I hadn't even thought of that possibility. Yes, the really wide commands where multiple entries/records are displayed horizontally are a real pain. Only saving grace is I think on a single Avaya version you can count on the fields being in the same order for each command run. That lets you index that array reliably, at least until an upgrade may change the field addresses. Let me know if you have any follow-up questions and thanks for the conversation.

— Reply to this email directly, view it on GitHub https://github.com/adpllc/altruistic-angelshark/issues/11#issuecomment-1150295606, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIBX4NVKHDEAUFC42QGYFTVODWAHANCNFSM5YHED2SA. You are receiving this because you authored the thread.