Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1231002

Summary: When migrate BPMS from 6.0.1 to 6.1.0 , existing deployments are not transfered
Product: [Retired] JBoss BPMS Platform 6 Reporter: cory <xiabai>
Component: jBPM CoreAssignee: Alessandro Lazarotti <alazarot>
Status: CLOSED EOL QA Contact: Dominik Hanak <dhanak>
Severity: urgent Docs Contact:
Priority: high    
Version: 6.1.0CC: kverlaen, xiabai, yulwang
Target Milestone: DR1   
Target Release: 6.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1238295 (view as bug list) Environment:
Last Closed: 2020-03-27 20:10:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1238295    
Attachments:
Description Flags
whole log file none

Description cory 2015-06-12 01:41:55 UTC
Created attachment 1037871 [details]
whole log file

Description of problem:

when upgrade to BPMS 6.1 GA ,our old process was gone.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. use old server backup  data, include 
   database
   maven repo(kie.maven.settings.custom): .m2
   bpms repo (org.uberfire.metadata.index.dir) :repo
   git server data(org.uberfire.nio.git.dir).niogit
   and .index 
2. start server
3. run sql script 
  update Task t set name = (select shorttext from I18NText where task_names_id = t.id);
update Task t set subject = (select shorttext from I18NText where task_subjects_id = t.id);
update Task t set description = (select shorttext from I18NText where task_descriptions_id = t.id);
INSERT INTO AuditTaskImpl (activationTime, actualOwner, createdBy, createdOn, deploymentId, description, dueDate, name, parentId, priority, processId, processInstanceId, processSessionId, status, taskId)
SELECT activationTime, actualOwner_id, createdBy_id, createdOn, deploymentId, description, expirationTime, name, parentId, priority,processId, processInstanceId, processSessionId, status, id 
FROM Task;


Actual results:
i find tables DeploymentStore just have org.guvnor:guvnor-asset-mgmt-project:6.2.0.Final-redhat-4 , do not have any old process deployment information and i find master branch of system.git don't have any old process deployment information.
If i restart bpms6.1 server , i can not get any process definition of old process and  process instance of old process and deployment unit of old process. 

Expected results:
All old process can be work.

Additional info:
Last month , i get successful migration for BPMS 6.0.1 to  BPMS 6.1.ER4 .
I debug this issue , i find some code change from 6.1.CR4 to 6.1 GA in here
https://github.com/droolsjbpm/jbpm/blob/master/jbpm-services/jbpm-kie-services/src/main/java/org/jbpm/kie/services/impl/store/DeploymentStore.java#L152.
In 6.1.CR4 , don't have this code.
Our old process don't have Attributes.so there will throw runtimeexception.

Please refer to whole log  in the attachment.

Comment 2 Maciej Swiderski 2015-06-30 08:17:23 UTC
this has been fixed by merging pull request and is available on master

jbpm
master:
https://github.com/droolsjbpm/jbpm/commit/977e1ad1937cb4e0d5462a764c0b15d76fa19215

in case in shall be back ported to 6.2.x please assign it back to me

Comment 3 Dominik Hanak 2015-10-14 08:28:39 UTC
Hi Maciej,

Are you migrating according to our Docs or do you use some scripts?
It is not clear to me how.

About the old data, what data should I have in 6.0.1? 

Thanks,

Dominik

Comment 4 Maciej Swiderski 2015-10-14 14:19:39 UTC
primary documentation though I am not going over it everything I try mainly due to known items that needs to be migrated. But relying on documentation is the way to go as that will be ultimately used by customers so much be reliable.

Usually just start bunch of processes (some complete some leave active) with user tasks and then upgrade to new version. These processes should still be available for execution after the upgrade.

Comment 5 Dominik Hanak 2015-11-05 13:07:53 UTC
Hi Maciej,

one more think I need to clear out. I am unable to find this in any Doc.

If I want to migrate from 6.0.1 to 6.2.0. Do I have to migrate to 6.1.0 first
and then to 6.2.0, or is it possible to migrate straight from 6.0.1 to 6.2.0?

Thanks,

Dominik

Comment 6 Dominik Hanak 2015-11-10 10:32:47 UTC
I have succesfully migrated from 6.0.1 to 6.2.0.ER5.
Here is what I've done:

1. Shut down running 6.0.1 instance with process deployed
2. Install/Deploy 6.2.0.ER5 
3. Copy 601/bin/.niogit to 620/bin/.niogit
4. Copy 601/bin/repositories to 620/bin/repositories
5. Make 6.2.0 to use same database (standalone.xml modification)
6. Execute upgrade scripts in order: 6.0.1 -> 6.1.0, 6.1.0 - 6.2.0
7. Run 6.2.0.ER5

I can see my deployments from 6.0.1 and I can work with processes and execute them.

Canceling the NEEDINFO because 6.0.1-6.2.0 Migration guide section was added into Docs.

Verified in 6.2.0.ER5.