25R2 Delivery continuity changes

It is possible, at least it was for me.

However, I noticed a slightly different behavior if the Entity was created AFTER 25R2 for some reason.

So for instance, entity RequestTask was added in 25R2. I’ve customized (added) a couple custom fields to it, but doing the regular CDB changes to add the fields would “work” during development (i.e. direct execution from Studio Developer), but it would fail during delivery, because during delivery it seems like it was trying to recreate the Request_Task_Tab table, which it’s not supposed to.

So for “newly released” entities, I had to make sure my CDB was using the new ‘#’ to add fields, i.e.:

For fields added to “older” entities (entities released by IFS before 25R2), I didn’t change my CDBs, and got zero issue during either development (direct execution) or during delivery build

For fully customized entities added before 25R2, I just had to add the Prepare_For_EBR command to the CDBs at the end

Although for  adding a new custom entity post 25R2 I would absolutely recommend using the new ‘#’ methods too)

If you do have the time and inclination though, I’d definitely recommend using the .ddlsource files instead, so that your customers would be “ready” for Delivery Continuity if they ever became a DC Customer. Even if you are NOT a DC customer, nothing stops you from being DC-Ready, if that makes sense :)

In short however, yes, it is possible to retain your CDBs, you just want to:

1. Prepare fully custom entities for EBR in their CDBs if they are older entities
2. You don’t need to do anything if they’re just fields added to older entities
3. You can still use CDBs but with the EBR Methods (#) for either new Cust Entities post 25R2 or adding fields to Core entities that were added Post 25R2
4. Generally speaking, you really want to use the EBR Methods for any new customization work undertaken post 25R2, basically, but the system is backwards compatible as long as you prepare your custom entities for EBR in your existing CDBs

Hi ​@SimonTestard ,

Thank you very much for sharing a detail explanation with the experience you had.

regarding the model inheritance changes like on work_task_tab  , i was thinking about this . As per documentation we need to keep core task untouch and add the customized fileds to usage task.

So like if we have added customized filed in work_task_tab , need to move those again to  like jt_task_tab or relevant usage task back , same as you did for request_task_tab thats what i understood?

Best Regards,
Wasana

To be honest the reason I added stuff to RequestTask is because with my 25R2 core files, I couldnt even generate the WorkTask entity at all!

I was getting this error even if I was not adding any field at all, so I have no idea what caused it, but that led me to put all my changes on RequestTask instead.

If it works for you, feel free to add to WorkTask directly, but yeah I’ve added mine to RequestTask because they’re only relevant to RequestTasks anyways, i didn’t need these fields to be present for any other WorkTask extension :)

Of course, if you’re doing an actual upgrade and there IS data in your custom fields, you need to be careful cause obviously moving those fields over is not as simply, you’re going to need a post script and so on to move the data over to the new fields (e.g. from work_task_rtb to request_task_rtb) and then making the work_task_tab custom fields obsolete etc. That’s a lot of work and testing required for that. I personally wouldn’t do it unless you truly can’t get your delivery working unless you remove your customizations from the WorkTask entity

Hi,

Thank you for the information. Yes as you said move to usage task for existing column is not easy though guide line says to keep core entity untouch if possible.

For the issue you got ,something with model inheritance syntax as per documentation.
 

Best Regards,
Wasana

Where did you find the guideline btw that says that? I’m interested.

And yeah the model inheritance I understand they should have the same DbObjversionStyle, but the thing is as far as I could find, they all did !

Like I didnt find any Entity that extends WorkTask that DIDNT have the same DbObjversionStyle, so it wasn’t clear at all which one was erroring

guideline here.

Entity Modeling - Technical Documentation For IFS Cloud

​@SimonTestard  yes as you said , i got the same error for WorkTask-Cust.enity and nothing shows where to add. But if you have customized extend entities like JTTask-Cust.enity or someother , then you need to add same style as below and no errors in code generation then.


codegenproperties {
   DbObjversionStyle "number";
}

Right cool, it’s probably cause I have a custom JtTask, but no attributes on it, just some modified PL/SQL, but I suppose maybe I still needed to enforce the codegen properties.

A bit weird given I’m not overtaking/overriding those, and the CORE JtTask does have the proper codegen properties, so I thought it’d just inherit it from the core file modeling :)