Project Transfer automation details

[mrt2100]

I see.  For further explanation, let me list out the steps in that part of my process:

• Connect to the model hosted in our cloud.
• Run a user created EA internal script to generate a local EAP file that references the model.
• Do whatever I need to do with the model.

The script I mention was written within EA and comes with the model I download.  I didn't write them but I seem to need to use them.  I was just going to try and remove myself from EA completely, but I got an answer from Sparx support saying that can't happen.  Though, they also included a white paper from LieberLieber Software explaining how I may be able to work around this, though it also may not work.

I'm going to give these instructions a shot but support insists that it's a long shot. 

[crequena]

Hi,

I have found this issue in the past, as well as some limitations on EA's API.

• https://www.sparxsystems.com/forums/smf/index.php/topic,40067.msg246536.html#msg246536
• https://www.sparxsystems.com/forums/smf/index.php/topic,39910.msg245866.html#msg245866

Since a solution was needed asap, I have developed a Java library that performs Project Transfer operations externally, at database level.
It is published in GitHub: https://github.com/krequena/eamodeltransfer.
The general documentation is here: https://krequena.github.io/eamodeltransfer/

The main advantages of this library are:

• No COM dependencies are needed.
• No GUI session is required (useful for headless servers).
• Works in 64-bit JVM.
• Can be automated with no restrictions.
• *-to-DBMS operations are supported.

I have to publish some examples yet, but it is already usable.


Kind regards,

[Paolo F Cantoni]

Hi, crequena,

I tried to find out in the Wiki, but I couldn't see this.  When you say it is done at a database level, does that mean you transfer table by table?  Further, if this is the case, are we able to add additional tables and they will be transferred also?

TIA,
Paolo

[crequena]

Hi Paolo,

Thanks for the questions.

Yes, it is a database copy done table by table, but only with the standard EA (t_...) tables.
Other tables present in the database are not copied.

Regards,

crequena

[Paolo F Cantoni]

Hi Paolo,

Thanks for the questions.

Yes, it is a database copy done table by table, but only with the standard EA (t_...) tables.
Other tables present in the database are not copied.

Regards,

crequena

I guess we could create a fork in the project to allow other tables to be copied?  Better still add a special table in the main repository telling which other tables should be copied.  That way, there's no need to fork, the project is self-extending.

Thoughts?
Paolo

[Geert Bellekens]

I guess we could create a fork in the project to allow other tables to be copied?  Better still add a special table in the main repository telling which other tables should be copied.  That way, there's no need to fork, the project is self-extending.

Thoughts?
Paolo

That table already exists. It's called usysTables
That's what the standard project transfer feature uses.

Geert

[crequena]

I guess we could create a fork in the project to allow other tables to be copied?  Better still add a special table in the main repository telling which other tables should be copied.  That way, there's no need to fork, the project is self-extending.

Thoughts?
Paolo

That table already exists. It's called usysTables
That's what the standard project transfer feature uses.

Geert

I didn't know about this feature, and seems more than necessary to develop it.

Paolo, feel free to open a ticket in the project repository

[Paolo F Cantoni]

I guess we could create a fork in the project to allow other tables to be copied?  Better still add a special table in the main repository telling which other tables should be copied.  That way, there's no need to fork, the project is self-extending.

Thoughts?
Paolo

That table already exists. It's called usysTables
That's what the standard project transfer feature uses.

Geert

It may well use it, but a simple test (which I first did a decade ago) shows, it ONLY copies the standard tables.

[Geert Bellekens]

try to delete it and then do a project transfer.

I had a client a while ago who, for reason, had a model with an empty usystables table.
A project transfer from that model was almost instantaneous

Geert

[crequena]

So relying in the t_uSysTables table could have some issue in some models.

Well, maybe a solution for my library could be working as it currently does (transferring all the well-known standard tables) and then copying any extra table present in t_uSysTables as an option.

Seems feasible for you, Paolo?

[Paolo F Cantoni]

So relying in the t_uSysTables table could have some issue in some models.

Well, maybe a solution for my library could be working as it currently does (transferring all the well-known standard tables) and then copying any extra table present in t_uSysTables as an option.

Seems feasible for you, Paolo?

I think that's a good start. 

I created a table in a Jet4 .EAP (but this time I didn't check if it was present in usysTables - but I believe it would have been). Did a standard project transfer and the table was missing in the target.  So I assumed that the standard process ignores other than the standard tables.

Paolo

[Edit:  Checked the logs and only the standard tables are mentioned]