検索

Resumen
· 13 dic, 2024

[Last call to participate] Internal Tech Article Contest for Employees

Dear colleague,

There is still time to participate in the Internal Technical Article Writing Contest:

✍️ Tech Article Writing Contest for InterSystems Employees ✍️

Write an article on any topic related to InterSystems products or services and publish it on the Developer Community by December 15, 2024.

🎁 Gifts for all participants + three main prizes for the best articles!

➡️ All details can be found here.

Artículo
· 13 dic, 2024 Lectura de 2 min

Intersystems Interoperability Enhancements with IRIS Whiz

The latest "Bringing Ideas to Reality" InterSystems competition saw me trawling through the ideas portal for UI problems to have a go at. 

I implemented the following ideas in the IRIS Whiz browser extension, so if you use the management portal to help with your day-to-day integration management this extension could be for you!

Feature Added: Queue refresh

Iris now has an auto refresh dropdown for the Queues page. Will refresh the queue at the interval selected. Does not load on Ensemble as it already has this feature.

Useful if you have an upcoming clicking competition and need to rest your clicking finger.

Implemented from idea: https://ideas.intersystems.com/ideas/DPI-I-487

 

Feature Added: Export Search as CSV

On the Message Viewer page you can click the Iris Whiz Export button to download a CSV copy of the data currently in your search table.

Useful if you want to do quick analysis on your data but don't want to use the fancy new Chart.JS page I spent ages creating (see that in action here!).

Implemented from idea: https://ideas.intersystems.com/ideas/DPI-I-566

 

Feature Added: Production Page Queue Sort

Added sort options for the queue tab on the production page. Defaults to sorting by error count. Click a table header to switch between asc and desc sort order. Use the search bar to find items quickly.

Useful if you don’t want to scroll to get to the biggest queue.

Implemented from idea: https://ideas.intersystems.com/ideas/DPI-I-628

 

Feature Added: Category Dropdown Case-Insensitive Order

Alphabetises the category dropdown list on the production page, regardless of case. Without this the order is case dependent.

Useful if you want to find things in the category list but don’t want to have to re-categorise everything into the same case to do it.

Implemented from idea: https://ideas.intersystems.com/ideas/DPI-I-625

 

Bonus! 

There’s also a refresh rate on the message viewer tab on the production page.  This will also refresh your queue tab if you select an interval and navigate to the queue tab. 

If you like any of these ideas please download the browser extension and let me know your thoughts. You can find a setup video on the OpenExchange listing which I recommend watching as you will need to complete some of it for most of the functionality to work!

Comentarios (0)1
Inicie sesión o regístrese para continuar
Artículo
· 13 dic, 2024 Lectura de 3 min

Speedier Message Viewer Analysis with IRIS Whiz

Prefer not to read? Check out the demo video I created:



As an interface developer I often get asked questions that require investigations into large quantities of messages. For example during a recent meeting our project manager asked me how many sites were actually using our newly set up orders interface.

Usually I'd be trying to copy the Message Viewer output to paste into Excel or simply run a message report for each individual site placing orders and using the message count returned…

This time however, using the Iris Whiz browser extension I had options.

 

Option 1 - Simple: Export CSV

An idea implemented from the InterSystems Ideas portal, simply click the Export as CSV button in the IRIS Whiz button bar to download the current search as a CSV file for easy Excel/Sheets manipulation.

 

Option 2 - Fancy: Analyse

In this case, I had just completed the Analysis tool in my Iris Whiz browser extension.

By adding the PV1-3.2 value to my message search criteria in Message Viewer I could easily run the report, click analyse and instantly have this information to hand in a simple doughnut chart - no exports needed.

 

 

Next, the project manager wanted to know what types of exam these sites were ordering. I added the OBR-4.2 value to my search criteria and re-ran the report. Clicking the analysis button now showed me the sites ordering and the exams ordered. (Each message search criteria is presented as a doughnut graph, tagged on to the end of the graph half of the analysis page)

Queue the third question.

Which sites are ordering which orders?

By clicking the required site in the interactive Doughnut graph I could view the data in the Data Viewer half of the analysis page. Another click on the filter button inside this box applies this data selection as a filter to all graphs - meaning that the exams Doughnut graph now shows the exams ordered for this site only.

Site graph and exam graph filtered by site:

 

And finally the hardest question.

When is this all happening?

Sifting through message times in the Message Viewer page to see when orders are being placed is a non-starter...

Fortunately I'd added a timeline graph to the analysis page.

I removed the filter and clicked the 'Show on Line Graph' button (toggled to ‘On’ for the PV1-3 chart in the screenshot above) to show the site data on the timeline graph at the top of the page.

A quick screenshot later and we were able to send out this report to our sites so they could confirm the number of orders for each day and ensure everything was working as expected.

These reports were to be run weekly, but luckily for me this task had become easy, especially when paired with the saved search function in the message viewer page so I never had to remember which search criteria to add.

 

Final Points

1. Sensitive Data:

The data in your Message Viewer search is sent to a new browser tab and as soon as the tab is closed it is gone - so no worries about sensitive data being saved in the browser. If you want to save a report use the default InterSystems functionality for Saved Searches and just run the report again at a later date. I had planned on a saving mechanism to save searches from the Analysis page but it didn't make the cut in this version.

2. Speed:

The analyse page is powered by the message search and I’ve put no hard limits into the amount of data it can show. The more messages and search criteria you add to your search, the slower the analyse page will go. With that in mind I’ve added a pop-up if you try to load more than 200 messages which allows you to choose if you want to load the bar chart at the top of the page or not. 

The bar chart shows every message as a selectable box. Clicking the box on the chart will add the message to the Selected Messages box in the data viewer (left) side of the page. You can then click the ‘View Selected Messages’ button to open these messages on a new page and take advantage of the message comparison features of the extension.

When clicking this button try not to have too many messages selected. Up to around 10 should be fine. 

Loading the bar chart with large data sets of 10,000s will definitely not be good for your browser but I've left it up to the user to decide.

3 comentarios
Comentarios (3)1
Inicie sesión o regístrese para continuar
Pregunta
· 13 dic, 2024

Condition for checking for non-empty string.

Hi,

My variable `check1` is a string.  It is either the empty string (for invalid/false answer) or a non-empty string for a valid/true input.  If it is valid, I want to return it.  I wrote this code:

    ret:$l(check1) check1

I do not like it once because it repeats the variable, but the main reason I do not like it is that if I do not insert the check $length(string) it will return false even for non-empty strings (due to conversion to integers for string prefixes).

I would like to ask you whether is there some nicer form in mumps to check for the non-empty strings than checking their length.

Thank you.

3 comentarios
Comentarios (3)1
Inicie sesión o regístrese para continuar
Artículo
· 13 dic, 2024 Lectura de 3 min

Lookup Data Tables avec TTL par entrée et tâche Purge Cleanup

Comme beaucoup d'autres se retrouvent probablement, nous étions obligés de faire un mappage de données en direct dans notre moteur d'interface, ce que nous ne voulions vraiment pas faire, mais nous n'avions pas de bon choix alternatif. Nous voulons uniquement conserver les mappages aussi longtemps que nécessaire, puis purger les lignes expirées en fonction d'une valeur TTL. Nous avions en fait 4 cas d'utilisation pour cela nous-mêmes avant de créer cela. Cas d'utilisation :

1. Le premier résultat ORU avec OBR-21 unique est converti en événement MDM^T02, tout ORU ultérieur avec la même valeur OBR-21 dans les 30 jours (flux de travail maximal possible) est envoyé en tant que MDM^T08 pour remplacer le lien de document existant.
2. L'ORM CPOE est généré à partir d'un résultat ORU. Le fournisseur résultant n'accepte pas les numéros de commande de remplissage et le moteur d'interface doit effacer le champ. L'interface CPOE doit avoir le numéro de commande de remplissage. Impossible de remplacer le numéro de commande de placement par le numéro de commande de remplissage car les techniciens cliniciens doivent référencer le numéro de commande de placement à l'intérieur des appareils du fournisseur. Le moteur d'interface doit ensuite mapper les numéros de commande de placement aux numéros de commande de remplissage pour ajouter les valeurs manquantes requises pour CPOE
3. Le fournisseur résultant ne peut pas modifier la procédure après le début de l'examen, et le dépôt des résultats doit être celui de la procédure la plus récente. Pour éviter de les traiter manuellement à chaque fois qu'ils se produisent, le moteur d'interface doit créer une carte pour toutes les nouvelles procédures après la notification de début d'examen et mapper les résultats à la nouvelle procédure. Le temps maximum pour conserver ces mappages de procédures est de 72 heures.
4. Le fournisseur ne peut pas gérer la mise à jour de la commande XO pour le message ORM de modification de procédure. Au lieu de cela, il attend une annulation (CA) pour l'ancienne procédure et une nouvelle (NW) ou une mise à jour (XO) pour la nouvelle procédure. Pour créer le message d'annulation, le moteur d'interface doit conserver une carte du numéro de commande à la procédure. Lorsqu'un message de mise à jour de procédure arrive, le moteur recherche la procédure précédente, envoie la commande d'annulation, puis met à jour le mappage persistant et envoie la mise à jour de la commande avec la nouvelle procédure. Il y aura un temps maximum qui devrait généralement être possible entre la nouvelle commande et une procédure de modification ultérieure.

Étant donné que ces scénarios conserveront des clés et des valeurs dynamiques en direct, nous souhaitons conserver les mappages uniquement aussi longtemps que nécessaire, puis purger les lignes expirées. J'ai examiné la classe LookupTable, mais elle ne fournit aucune fonctionnalité TTL. Nous avons donc écrit notre propre classe appelée LookupData.

https://codefile.io/f/vEgnWzafOx

Il s'agit de ma première classe que j'ai développée à partir d'une feuille blanche. Je suis ouvert aux critiques constructives sur la manière dont cela peut être amélioré. Je suis sûr qu'il existe de meilleures façons d'exécuter certaines méthodes, donc j'apprécie vos commentaires.

Comentarios (0)1
Inicie sesión o regístrese para continuar