Hi @Raj Singh@Lorenzo Scalese , @Evgeny Shvarov 

  • I'm fully for developer-to-developer initiatives.
    • though in practice, this is too often developer-to-nirvana 
    •   
  • dark-corner:   
    • several months back I suggested having an ARCHIVE option
    • so that packages stay in OEX but don't show up in the directory 
    • if not explicitly requested similar to SPAM in DC.  
    •  
  • But something like this seems to exist already.
    • My recent update of my OEX web sniffer found 2 packages
    • that do NOT show up in directory.
    • don't ask me how this works but that tool is there somehow.  
    •  
  • The actual critical corners might be identified by a combination of
    • LastUpdate in OEX and pending PR.
    • >>  

 

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 !


 

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