Static Tables in Orchestrator

Feedback Orchestrator
, ,
1

Hello Team,

Another idea is to have the option to create static tables in the database. These would act as reference tables and could be used for two different purposes…

  1. A Config file for the process - instead of having a separate Excel file - in fact I think that all processes should by default have a config table within Orchestrator
  2. A reference table for specific processes, e.g. this table should be something that can be referenced from the process. For example, a list of valid airports that can be flown from. Again , this removes the need for separate Excel reference files.

These tables could be created in a similar way to present with perhaps a check box to say whether it’s a reference table and therefore should not be consumed in the way current queues are.

RD

2

This would be great. It would remove the need for separate end-user computing controls over the spreadsheets & would make it harder to make accidental changes to any files.

3

Not simple.

You would need a viewer on top of that table so that you are able to insert/edit the list of airports.
There would be migration issues and inconsistency between different databases.

I guess it will be hard to be administered from a SQL view point.

Alternatively you can use any SQL Server Database and create tables into it + custom activities.

I would not mix these with the Orchestrator DB.

4 Likes
4

Current queue items, once processed can’t be re-used. I think the ask here is to possibly create a queue where items don’t auto complete and instead activity is used to complete it. That way, we could load Config Excel, or possibly data that is static through out the process, and could then delete/complete/change status per item in queue via activity.

My example is - grab list of accounts, put it in queue, get it from queue to be checked on another site, if value not found re-check again after 30 min … I would love to have them available in queue again vs spending time grabbing the list again and adding to same queue. Right now I’m using Excel to do that, not ideal because Excel has to be installed on each VPC (yes tried without installing but Excel Activities we are using requires installation) - so license cost for Excel :confused:

5

@richarddenton remember that you always can build your own DB and do it for yourself … excel files allow clients to change simple parameters without knowing any passwords :slight_smile:

6

That is not the point though. To access own DB I have to now prevision robots to gain access to DB, which means security / risk. Queue is already there, all it needs a change that does not auto complete the task but instead must be done manually (like a status column) - then I don’t have to do DB or Excel or anything else.

If I was to use your theory, then one could say why do we have queues to begin with. Why not use Excel or DB? It’s called competitive feature. One stop solution. Better then the other guys.

2 Likes
7

grab list of accounts, put it in queue, get it from queue to be checked on another site, if value not found re-check again after 30 min …

Please investigate the use of the Postpone activity, and also Get Queue Items (requires a bit of fiddling with filters)
Also, please note that Queues have been designed with auditing in mind, which is why there are no actual deletion (just flagging as deleted)

8

That is not the point though. To access own DB I have to now prevision robots to gain access to DB, which means security / risk. Queue is already there, all it needs a change that does not auto complete the task but instead must be done manually (like a status column) - then I don’t have to do DB or Excel or anything else.

If I was to use your theory, then one could say why do we have queues to begin with. Why not use Excel or DB? It’s called competitive feature. One stop solution. Better then the other guys.

Couldn’t agree more! Everything we do now is to move away from the use of Excel sheets and adhoc databases.

Totally understand that there are workarounds but storing reference data and process config information is fundamental to almost every process we create (even the Framework has a config file now, which I like in principle but hate that it’s in Excel!!)

@badita appreciate this may not be an easy change but nothing worth doing is easy right ? :smiley:

1 Like
9

Still think this is a good idea :slightly_smiling_face: