When creating corticon rules that depend on rest calls to fetch data, is it possible to setup the URL as config.
We cannot "hardcode" the live environment string into the package at compile/deployment stage.
Currently the rule validates the URL and we dont have access to live env from our dev and test sites.
Also with up to 3 development and 9 different client test sites and then live, you would have to switch and rebuild
the rule deployment a lot if this is hardcoded.
The REST URL is part of your vocabulary datasource definitions and can be separately deployed through the datasource.xml file at deployment time. Simply compile your EDS and export (and modify) the URL and its credentials in the exported datasource.xml for your target run time environment, which you then deploy together. Alternatively, you can predefine multiple REST datasource definitions in your vocab, and have a branching container in your ruleflow conditionally running the specific REST service callout for a target datasource based upon a decision service request parameter.
Hope this helps and above will work for what you have in mind. Best regards, Harold
Harold, do you maybe have the Corticon 6 documentation for us ? We have tried modifying the datasource.xml, but it still keeps looking at the old URL of the previous environment.
Do we have to recompile the EDS with the new datasource.xml ? or can we just ship the datasource.xml with an already compiled rule set ?
Hey Abri, I recommend you install the Corticon 220.127.116.11 HF. The 0.1 HF solved an issue with the deployment of decision services. Here you go with its description: "COR-6839 : Modified the Corticon Studio deployment wizard to upload the latest datasource.xml associated with a vocabulary when deploying a decision service to a Corticon server." Another work-around is to unpublish your decision service in the Web Server Console and republish from Studio with the correct datasource credentials. Let m eknow how things go! Regards Harold
I discussed this one of our developers today and there is some nuance in the handling of the datasource.xml for REST datasources. The datasource.xml can be used to change the user credentials but not the URL. This stems from an optimization where Corticon instructs the underlying REST driver to use the REST schema discovered at design time. This optimization eliminates the need to do runtime schema discovery. The downside is that the driver "burns" the URL into the schema and we don't have a mechanism to override it.
In the short term, your would need to update the URL in Studio and regenerate your EDS file to change the URL. We recognize this is not ideal and will look to provide a better option in the future.
James, this is a problem for us, the corticon rules are not built by us, it is done by an external party. They only supply us the
We only deploy the compiled rules, and have up to 9 test/UAT/Prod environments that we need to move between.
We also have another issue, where in design time it validates the URL, but we do not always have access for the external party
to the live environments, so they cannot build the URL into design time.
Is there a timeline currently to look into this or have a solution for it in the future ? We are giong into UAT with a new client from 1 April
so this is rather important at this time.
Should we log a tech call for this ? or how do we go ahead to try work out a solution ?
We're waiting to hear back from the Data Direct team that produced the REST driver if there is someway we can override the URL in the schema.
An alternative we might be able to provide is to not use the REST schema stored in the vocabulary. In effect what would happen is the REST datasource would perform schema discover from the REST service. This was the original behavior but we opted to store the schema in the vocabulary to avoid the overhead of rediscovery and to avoid potential schema discovery problems at runtime. One approach we could use here is to have a property to force the schema to be rediscovered. It's not ideal because you have the one time hit on load at runtime but it's somethign we might be able to do without requiring a driver change.
One option we were discussing, was to do the schema discovery at deploy time ? This might be some work on your side though.
But if we can cache the schema on the first execution it would also work.
We're still investigating options for this. We've ruled out rediscovery of the schema. This would not work if you exported the schema, tweaked it, and imported it back to the vocabulary. We expect this to be fairly common and want a more robust solution. We've got a request into the driver team to look at this. We're also investigating if we can manipulate the schema directly to replace the URL. I'll update you once we know more.
Thanks a lot Jim.
When you mention changing the URL, are you talking about just changing the hostname portion of the URL, so that you can 'aim' the same request at different hosts, or are you talking about changing the URL against services with different responses?
Could you please post a sample of two different URLs, so we could see what is the same and what is different between them?
We typically have a Maintenance environment MNT and an internal testing environment, QAD, on one server.
We have a SIT and UAT on a client test machine and then a LIV production environment on another machine.
This can be more as we can have testing, training or project specific environments.
The system calls to Corticon to calculate a premium for instance. Corticon needs some rating information,
this can come either from our own application, or from another external system. Corticon now has to call a service
to get this information.
The service being called, should return the rating data, so the output dataset from the service should be consistent,
if it is not, we will put a transformation layer between the two (Pilotfish is the tool we use)
This can even convert from different technology like flat file or webservice to a REST call.
To Corticon however the service will always look the same (signature and method name) although
the dataset might not always include all possible data.
What will differ is, it might be the MNT env or the QAD or the UAT or LIV (where our devs typically do not have access,
so they wont be able to access the service in Production (we will have a user that Corticon uses that is valid in Prod).
We're exploring how Corticon (independent of the driver) can replace the URL in the schema when the EDS is loaded. We may have something to try next week.