Deleting a record or records in Corticon using ADC

What version of Corticon Studio do you use (including possible hotfix version)?

5.7.2.2

I started to go another ways since I didn't see a response yet. I basically, retrieve the error messages that I want to delete and in my next rulesheet, I try and use the entity remove function. Although it removes the error messages from memory, it doesn't delete them from the database.

I guess this is a silly question but Do you have to have EDC also enabled if you are using ADC? I thought the two were mutually exclusive.

Then I guess I'm missing something. I cannot delete records from he database. I am using ADC, I have pulled in the records that I want to delete, then, in the next rulesheet, I am checking a condition and then issuing a remove directive on the Entity. I would assume this would remove the data from the database. Is there something in ADC (not unlike EDC) where you can switch between read-only and read/write?

Here's my workflow:

and

(the errors are at the bottom, need these removed from the database)

and

All this does is remove the 4 error rows from the output in the ruletest. The details in the database go unchanged.

Also, I noticed that when I try to deploy this to the server, the Database mode = none and the Entity (all incoming) instead of "only new" is selected. They cannot be changed.

I was able top change these settings using EDC. In ADC I cannot.

Thanks,

Branden

Hi Branden,

I must admit I have only used READ, WRITE and UPDATE within ADC thus far, which work fine.

Did you enter any values in the Runtime Properties of your Service Call-out? You have to specify your Datasource name (e.g. your ADC Datasource) and a Query Name there (the query containing the DELETE statement).

If you created a DELETE statement in your CORTICON_ADC_WRITE_DEFS and the records are still not deleted, then this sounds like an ADC bug to me. Or perhaps the DELETE statement isn't supported in ADC, something I can hardly imagine. But maybe I am overlooking something, as I cannot find other statements than READ and WRITE in the documentation.

If I had to work around this as a temporary solution, I'd flag the records that I want to file for deletion (delete T/F) via ADC WRITE and exclude the flagged records from a new read (and perhaps create a new EDC enabled Decision Service to delete the records that have a flag). This is not a great solution to say the least, but it might work for now.

Let me know if this works.

-Gertjan

Thanks for your response. Yes, I added the necessary property information for the service connector. It's like it just ignores that part of the workflow and then moves on the next. No error, no warnings. It just bypasses that part and moves on down the line.

Unfortunately, I cannot modify the DDL of the table so I cannot add a logical delete flag. That would probably make things a bit easier.

You mentioned adding EDC. Do you mean have both ADC and EDC enabled in the same vocabulary? Wouldn't that cause continuity issues on the Entities? I was under the assumption that ADC had the same functionality as EDC just with enhanced custom SQL capabilities. I have not seen anywhere in the documentation when they have enabled both. I would be interested if you knew where I could find this information.

Thanks,

Branden

Branden, the Corticon 5.7.2 documentation's Data Ingration Guide introduces "Getting Started with Multiple Database  Connectivity" with

Corticon's database connectivity reaches another level when it enables a rules project to access more than

one Datasource. You could mix one EDC Datasource with several ADC Datasources, performing

Rulesheet-based action and filters while the ADC implementation uses multiple Service Call-outs on a Ruleflow.  Together, these enable the Decision Service to be running queries on one database, processing that data, and   then possibly branching to write to either of two other databases.

GS,

Yes, I know it's possible to have more that one data connection, but for my purposes, a single instance is necessary. Now, as far as having both EDC and ADC mapping to the same entities in the vocabulary, doesn't that create a continuity problem? I remember added them both when I first started and getting all kinds of mapping errors. None seemed to be legitimate. I ended up just creating a new project and enabling ADC only.

Thanks,

Branden

Hi Branden,

I have a couple theories on what is going on, but without a detailed Corticon DEBUG log, I can’t be for sure.

First, there is a slight difference between EDC and ADC .remove.  Because EDC is completely integrated with Hibernate (Corticon’s bridge technology to a database), when the Rules do a .remove, this Entity instance is removed from Corticon's working memory and also the database.  However with ADC, you will need to first remove the instance from the database (using ADC.write Service Callout) and then remove the instance out of Corticon's working memory (using a .remove operator).  Order matters in this case.  The call to the ADC Service Callout must occur before the Rules do a .remove.  ADC bases its operations on Entity instances that are in working memory, so if the Rules do a .remove first, then ADC.write has no instance to work with.

Second, there is an issue with your CORTICON_ADC_WRITE_DEF -> SQL value.  

DELETE FROM cms_ef_error_log WHERE earnings_file_id={CmsEfd.earningsFileId} and attribute_name={Static.attributeName}

You are pulling variables from two different Entity types … CmsEtd and Static.  ADC.write explicitly checks for this condition and creates a Rule Message stating that this is a problem and stops processing.  There are many reasons why we prohibit the use of different Entity Attributes inside the WHERE clause.  One main issue is that it would add complexity to the feature which could confuse the user.  Even though, in your case, there is only 1 instance of Static in memory, there is no guarantee that this will always be the case.  Imagine that there are 2 or 3 instances of Static in memory, with each one having a different “attributeName” value.  The paradigm of each PRIMARY_ENTITY instance representing 1 row in the database falls apart.

The easiest work-around is to add the Static.attributeName value to the CmsEtd Entity through a Transient Variable.

Here are the steps:

1) Create CmsEtd.tempAttributeName as a Transient inside the Vocabulary.

2) Create a new Rulesheet which will copy over the Static.attributeName value into the CmsEtd.tempAttributeName.

3) Update the CORTICON_ADC_WRITE_DEF -> SQL value to :

       DELETE FROM cms_ef_error_log WHERE earnings_file_id={CmsEfd.earningsFileId} and attribute_name={CmsEfd.tempAttributeName}

Now, the SQL only contains Attributes from Entity CmsEtd.

And lastly to address your ADC and EDC question from last posting, it isn't advisable to mix and match ADC and EDC in the same Vocabulary.  You are correct that there could be continuity and synchronization issues.  Some Entity instances would be managed by EDC (Hibernate) while other would be managed by ADC.  It can be done, but only in specific cases.

I hope this helps.

Regards,

John

John,

Thank you, that's what I needed. I tried that before, but I realize I left it as Base instead of transient which makes a huge difference. Thank you for your help!

-Branden