New post
AllAccepted answers
Robert Cemper · Sep 23

Sorry, there is a bug:

from config.py:

# Default config variables
import json
import os
import sys
import base64

APP_PATH = os.path.dirname(os.path.abspath(__file__))
JSON_CONFIG_PATH = APP_PATH+"/config.b64"
.....

BUT it is missing in your repo:

irisowner@2bbb2b066320:~/dev$ irispython ./rh/flask/main.py
/home/irisowner/dev/rh/flask/app/config.b64 not found

Ooops !


 

Robert Cemper · Sep 18

No discussion: Business Operation and Outbound adapter is a combination you should not break 

But to trigger a second Business OP You just need a Business Service that you kick,
no need for a Busines Process in between. Old ENSDEMO shows such examples.
eg. DemoRecodMapper

Here the FileService is the driving part.
another example uses a service that triggers itself DemoDashboard

It just lives on his timeout setting
Here it has nothing to do then updating some properties
But it could be anything. eg Kicking another Business Operation

Robert Cemper · Sep 15

Translation from the French community posted by @Lorenzo Scalese 
----------------------------------------------------------------------------------------------------------------

Hi,

ISC should keep a copy of the original repo until a new release on OEX (this is eventually the case already)
If a package gets orphaned, it seems to be complicated to hand it over to another member of the community if this copy doesn't exist. 

The account on GitHub could have been closed or the repo could have been deleted. This complicates the situation. We could. of course, try to recover the content from ZPM. But this could be wuite a huge effort of re-engineering. [ If it is available in ZPM at all. -rcc]

Regarding the deletion of the package.
I'm not against the idea, IF there is a valid reason.
It happened to me that I deleted a package because a new functionality of IRIS made it obsolete.
Anyhow, I left the repo on GitHub public in order not to lose the contained knowledge.

In that case, we could decide on an option to "archive" the package 
Not everybody works with the latest version of IRIS. So this might be interesting in some cases.

----------------------------------------------------------------------------------------------------------------
Thank you & Merci @Lorenzo Scalese 
 

Robert Cemper · Sep 14

You can see 2 examples of the adoption of orphaned  OEX packages here:

Besides the pure bug fixes, I applied some other enhancements for comfort

  • pointer to the orphaned predecessor
  • fixed Dockerfile to be version-independent
  • fixed pending mapping of SuperServer
  • added support for IPM
  • added installation guide
  • added quality tag
  • added demo server
  • added screenshots
  • enhanced README

Case #1) https://openexchange.intersystems.com/package/JSONExportManyToMany
OEX>>> https://openexchange.intersystems.com/package/JSONExport-ManyToMany-AD
GitHub:  https://github.com/rcemper/JSONExport-ManyToMany-AD

Case #2) https://openexchange.intersystems.com/package/Samples-FHIR-Oximeter-Devices
OEX>>>  https://openexchange.intersystems.com/package/Samples-FHIR-Oximeter-Devices-AD
GitHub:  https://github.com/rcemper/Samples-FHIR-Oximeter-Devices-AD

The packages on OEX are still pending for approval and not public yet.

Robert Cemper · Sep 9

Today I had to process a rather sad exercise. 😢

For about 15 recognized packages in OEX I had to cancel my previous reviews
because the packages were broken. 
They could have been fixéd easily as there were PRs ready.
But for more than 3 months these fixes were just ignored by their owners.

On top of it:
A significant part of them was highly awarded in previous contests

I'm deeply disappointed, as the Quality of Packages in OEX was a personal focus.
However, I have to accept that quality has lost importance also in this
narrow section of my life.

😞

Robert Cemper · Sep 5
  1. SMP > System Operation > Databases shows the size o your DB   8192 is the default you have to match te blocksize of your backup source
  2. /usr/lib/iris/mgr/ is IRISSYS or the HS equivalent a direct restore may destroy your running installation. restore it in a parallel DB and import only uncritical parts.
  3. in SMP > System Adnin > Config > Sys Config > Local DB  you can set the Blocksize of the DB before creation: Blocksize might be hardwired in Community Distribution