Enabled /Disabled or Active/Inactive object flag

Hi

We often have objects that are in production but then for some reason are no longer needed or have been replaced with alternative "version" and we still wish to keep the previous "version" - just in case. We do use the Version Control during object development - but this comes into play is later, where we want to 'park' the whole object and introduce a new one. Therefore, to avoid polluting the Object explorer with legacy objects I MOVE them into another Project called zRetired (see image). The challenge is that you need to 'break' any references to these retired objects so that they are not accidently used by an active workflow.

What would help is if you could flag an object as Active/Inactive. That way if an Inactive Object is called by an Active Parent Object, then an Exception/Error could be raised and the whole flow is Aborted. The preference of course would be to pre-parse the workflow looking for inactive objects and abort before anything is actually executed.

Alternatively, perhaps a special Project could be created that is Inactive and any object in it becomes automatically Inactive and anything in an Active Project that calls something in the Inactive Project will Fail/Abort and alert the Runtime engine somehow.


 

Just a thought as we have on occasion had an issue where a retired object was executed by something we had missed changing.

cheers
 

That sounds like a good idea we will add it to the list of things to do


I have a question.

We do not have any security at the moment.
Do you think there is a need for it? 

Potential user Roles:
Administrator
Security admin
Developers

Sharing connections

EG "user A" can work with data source 1 
EG "user B" can work with data source 2
 
Project owners ETC
 

Hi. And thanks.

My dev team is small (was 2 and now is 1 ). Hence security in this context is not front of mind. 

However, I can see several Use Cases where this would be a handy feature.

* Public style Read-Only access where you need to allow another user or group of users the ability to see but not touch the Workflow. Maybe there is a need to troubleshoot why something downstream has not happened. For example, in our case we receive inbound data in numerous formats, typically via email that is then validated, transformed and loaded into a database. Stage 2 of the workflow is to take that data and apply Business Logic to work out a "value" (won't go into detail). This value or even a set of values needs to be then pushed to a high-end back-office system. IT controls the first stage and then a separate Business Operations Unit manages and has access to the Backend System, and it may be handy for them to be able to step through the process in a troubleshooting phase with IT to establish what went on.

* I have built a WebApp that shows our Business Units the results of all of these inbound (and outbound) ETL workflows in a summary form by recording the ETL events along with useful metadata in a centralised database table that is READONLY to these groups. It would be good to somehow use elements of the Management Console to allow them to navigate from My summary view through to things like the Logs and Scheduler etc to provide a complete view of the workflow in READONLY and secured approach. My App security is controlled by Active Directory Group Membership and so it would be good to have Single Sign On kick in with mapping to AD groups such that there is no need to maintain a separate set of credentials and user/group memberships.

* Another possible Use Case would be where you wanted some Subject Matter Experts to manage the transformation of the data from say an inbound excel file into a database staging table as perhaps the data is sensitive or private and then have someone in a technical role build and implement the workflow without any first hand knowledge or even visibility of the data being moved around. 

In short, I think it would be a worthwhile enhancement. Having said that, I do recall I think it was an IBM platform at one time that had this and it just seemed to be over-engineered for small dev teams and led to a lot of things to do before getting started which led to frustration etc.

Hope that helps
 

Having thought about disabling objects,
I think The best approach would be to write a warning into the execution log.
Users may disable objects by accident and suddenly become famous.

 

Your suggestion was implemented in the latest release.

You would need to patch the repository though.

www.etl-tools.com/articles/major-release...ocessor-6-4-0-0.html