Is there a way to automate the catalogs of each questionnaire to be able to connect it with an internal API and be able to load new entries automatically?
For example, in the image of “marcas” we are having the need that every time we create a new option in our legacy system we need to update all the catalogs of a specific version.
We have reviewed as a team and we think it would be a good option to have global catalogs or categories that allow us to update their entries through APIs. I mention the above as an opportunity to improve the application.
@mcastillo, recall, that any changes that you do on the Designer will not take any effect unless the updated version of the questionnaire is imported to the data server.
Correspondingly, before importing the questionnaire to the data server, log in to the Designer and [manually] update the categories you want to use by uploading the single actualized file containing all of them at once:
This should be trivial to do if your other system can export the categories in exactly the format that Survey Solutions expects for categories (tab-delimited or Excel formats).
Thanks Sergiy, the problem we are having is that the monthly changes on a price survey are many and means that every month the user has to enter the information manually both in the legacy system and in Survey Solutions. We have also looked for a way to directly access the postgrest table of the categories but without success yet, we will inform you for forum documentation if we achieve something through that method.
What is a “legacy system”? It is an internal system which collects the information.
What capabilities does it have? It has the ability to analyze the data we collect in the field.
Why are there two parallel systems creating duplication of work? They are not systems duplicating work, when collecting information through Survey Solutions we need to be able to process it.
Having said the above, we are having problems since the data source is our internal system which updates its categories or catalogs every day and that is why it would be very useful to create global catalogs that allow the user to add new records to these categories.
Does it have a capability to run scripts? Which language? Does it have an API that can be called from outside?
Well, this is what I read from your question:
So, currently the users have to maintain both systems by uploading the same categories in each system. Even if the systems serve different purposes, the task of maintaining the categories is currently duplicated.
I think the key is to simplify, but I don’t know the details of what you are working on. If this is a price survey, then you shouldn’t encounter this complexity really. Check the PUBLIC EXAMPLE Price Survey which is something I’ve distilled from an earlier and more complex 2016 questionnaire that I was working on.
Also, is this a real project? or a theoretical consideration?
Well, that’s some very high frequency survey then!
Does it have the ability to run scripts? What language? Do you have an API that can be called from outside? Yes, it is a system developed in C# as a backend through APIS.
I think the key is to simplify, but I don’t know the details of what you’re working on. If this is a pricing survey, then you should not encounter this complexity. Check out the PUBLIC EXAMPLE Pricing Survey, which is something I pulled from an earlier, more complex 2016 questionnaire I was working on.
**Thanks Sergiy, it really is a simple example of a system that records prices but it determines all the catalogs that are loaded as categories in survey solutions, what we propose is that the categories in some way be global and accessible through APIS in order to automate that when a new entry is created in our system, create the same one also in Survey Solutions in order to synchronize both systems, this really is more of a contribution of an idea for you to take into consideration in future updates. ** On the other hand, I think that the example you sent me is not public, it tells me that I lack privileges.
Also, is this a real project? Or a theoretical consideration? It is a system that we currently have in production and begins data capture in 1 week.
