Question about migrating data

If I were to recreate a v7.6 process in v9.2 without actually using the migration tools...

Would I be able to migrate the data?

I have a process in which all the action names and stage names have spaces. I really don't want to make the change in production (and test) only to migrate and basically retest everything from scratch again.

I understand the requirement to make changes in v7.6 with duplicate actions - but the blank space one is troubling to me due to the duplicative work.

Find more posts tagged with

BPM

Comments

Michael_Turek

Opening a ticket...

Brian Mellert

A ticket may be a good idea. I suspect you may be able to migrate data, but you'd have to either do your own extract/convert/insert of data into the table. Alternatively, it may be possible to run the migrator to get the mapping file layout, edit that layout to the V9 specifics, and use that as a stepping stone to migrate data. I know while rewriting to V9, I'm eliminating several "junk" variables since they are no longer needed and hope to take this approach. (I haven't tried it yet to verify it works, but theoretically it should if I edit the mapping file correctly.)

Michael_Turek

That is essentially where I am at. In my post I did say write from scratch - but I did use the migrator tool to create the map - it does have a mapping file.

But, I ended up changing just about everything anyways except for the layout. I don't mind the recreate as the new features (c# / visual scripting / bus. objects) should be worth it. And it seems there is little option otherwise - unless you stay on 7.6 forever.

I'll post the whatever comes out of the support ticket.

thanks

Marzuk Fareez

Hi Mike,

I would like to help you on the part of problem you are facing with migrating data, If you wish we could go on a call a call to discuss about it.

Michael_Turek

I opened up a ticket and did briefly talk to a help desk guy. He was somewhat helpful in that I was able to bounce things off him in regards to the migration.

I don't know if I misread the pdf for the file migration, but it sounded like I needed to change any stage/role/action on the 7.6 map first. Which I could not do - because I had too many changes and did not want to do this on a production 7.6 map when I got there.

So - while waiting for the ticket - I went ahead and did the file migration (using a dev enviornment) and by trial and error - found out as long as I didn't change a whole lot (like add to and remove from the map), migration was ok. I had to update the mapping file for just about every action/stage/rolename/ procedure name. It was a learning experience and I still need to test the 9.2 map.

So - all in all - I was mostly concerned about needing to change a prod 7.6 map - but didn't need to.

Jerome_Pearce

If you use the repository migration tool, you need to have used the code migration tool and keep the 'mappings' file for the repository migration to work.

If you are doing the migration manually, there are a number of quite important updates that need to be made to the data - it is not just a simple 'copy over'. We have successfully managed all aspects, but you need to be sure to address the following:

All SQL involving Role names, as they likely change.
All SQL involving Stage names, as they likely change.
eWait entries need careful copying
Folder name suffix sequences need updating
Attachments need updating
eAlert need updating with captions
eAssignment needs updating
eFolder records need updating
ALL null dates (01/01/1753 00:01) need setting to null

There may be more, I cannot recall now....

And if you are using (h)Oracle, you will have to mess even further as you cannot copy CLOB data from one database to another (gotta love Oracle, eh?).

Michael_Turek

Point well made Jerome - probably foolish to go the manual route -when the tool given does the job

Jerome_Pearce

Well, in some cases you have to do it manually. We have one system that took 24 hours to migrate the largest process, and had not completed (no indication of progress). As we need to migrate the whole system of 8 main processes in less than a weekend, we decided to do this manually. If anyone wants to know how, we can offer information of a successful manual data migration.

Michael_Turek

I see what you mean.

I just came across issues where the migrator didn't import ewait. There should be some timers going to archive stages.

Also when looking at eevent the values in eactionname seems to be the ealert.ecaption values. And not what I put in the mapping file.

Has anyone experienced this?

Jacob_Eastman

If you are on Oracle, you can manually migrate the eWait with the following where VER9 is your v9 schema and VER76 is your 7.6 schema

insert into VER9.eWait (EFLAGNAME,EWAITTIME,EFOLDERID,EMAPNAME,EENGINENAME,ETHREADNO,EPRIORITY,EFLAGFOLDER,EACTIONNAME)
select EFLAGNAME,EWAITTIME,EFOLDERID,EMAPNAME,EENGINENAME,ETHREADNO,EPRIORITY,EFLAGFOLDER,EACTIONNAME
from VER76.EWAIT

Afterwards, run the following to update the eWaitTime to the v9 format:

UPDATE eWait
SET eWaitTime = NULL
WHERE eWaitTime = TO_DATE('1753-01-01 00:01:00','YYYY-MM-DD HH24:MI:SS');

If you are on MSSQL, slight modifications to the above should work for you as well.

Jerome_Pearce

It assumes you want to copy the entire table, whereas this issue is about one process. This is misleading at best.

That also does not address the issue of the Data Migration tool not copying the eWait entries over.

Michael_Turek

Thanks for this.

Brian Mellert

Doesn't bring over eWait entries?!? :smileyfrustrated:

That will be painful at best as we have lots of entries. I'll have to keep an eye out for that ... or maybe the next "migration tools" enhancement -- tentative due in July it looks -- will handle those better. (I won't be converting data from my main process before then anyway, I have to start converting the code itself which will take that long.)

Michael_Turek

It's hard to tell yet why it didn't bring the entries over. The only think I can see what is similar is that they all were timed actions going to an archive stage (changed the name).

I'm also using a develepment environment which has limited data.

Daniel_Michael

Another note about migration with Oracle. 11.1.0.7 (Patch set 20) is the best client to use.

You could also scope Jacob's SQL using a where clause if you wanted to scope to a map or just do certain actions.