Merging serveral Enterprise Guide projects into one

[andreas_gryn]

Hi

I have several EG projects (6.1) that I use.

To have a better overview and easier execution I want to merge them.

All projects have 1 process flow.

The new project should therefore have several process flows.

Is it possible ?

Thanks for the response.

Kind regards

Andreas

[jakarman]

In one egp project you can define multiple process flows, it is documented just create and name them as you like.

The autoexec process flow has a special meaning

[andreas_gryn]

Yes, that is true.

But can I copy an existing process flow from project X to a new process flow in project Y without having to redo all the work?

[Kurt_Bremser]

AFAIK, you have to mark all objects in the source process flow and copy/paste them to the new process flow in the target project.

[andreas_gryn]

Hi

this seems not to work.

I can select everything (edit => select all) but can't copy (greyed out).

Also Windows keys don't work.

[Kurt_Bremser]

I see, you need to copy the flow information and not only the items in the PF.

That seems to be impossible at the moment.

Do you have complex flows with conditions or is it simple A -> B -> C chains? If that were the case, you could try to export the whole code of the PF and handle it from there as a single program source.

[jakarman]

Drag and drop on each item is working (code not connections). The new prjctflow is needing to have one item. Opening up two Eguide sessions could be am approach.  

When the projectflow is not too complicated it can be done that way.

[jwillis]

Dear Jaap and Kurt,

My EG books say that you cannot have two projects open at the same time.  Can you please expand on your suggestions and explain how to open two projects at once so that copying and pasting are possible.  I am new to EG. 

[Kurt_Bremser]

What Jaap said, you can start as many instances of EG in parallel as you like, so you can copy/paste from one to another. Since 4.2, you can even have multiple versions of EG installed and run them concurrently.

What may be limited is the number of workspace servers that a user can run at one time; I do that to keep my users from overloading the server.

[jakarman]

As far as I know and did You can start as many Eguide sessions as you can manage. That is common Windows behavior.  (it could be modified/blocked by some IT person)
Having started those Eguide sessions each one can open an other project (egp file).  Technical it is a zip-file with some folders and XML-files.
At this point common enqueing/locking is to occur.

There can by only 1 (one) running Eguide session that is capable to update a specific Egp project.
A specific EGP project may be opened and shared by many EGuide sessions at the same moment with just read access.
Nothing different as using office with word ppt or excel. The same approach.
A common confusion as there are many dogs called max but not every dog is called max.

[Kurt_Bremser]

Now that you mention it, I completely overlooked that the .egp is a "simple" zip file with xml's.

I just created a sample project in EG 4.3 to get a feel for what it looks like.

In the root of the zipped .egp, there is a project.xml that describes the complete project structure. Elements are stored in directories that have their UUID's as names.

Maybe this could work:

- Unpack the "target" egp into a directory tree

- from the "source" egp's, copy the subtrees (elements) into the directory tree

- from the source egp's project.xml's, copy the relevant "elements" sections into the target project.xml

- do the same with the "process flow" blocks, changing the <Label> values accordingly to avoid collisions

- pack the directory tree back into a new .egp

One obviously must be careful, though, to avoid duplicate names in the elements.

Edit:typo

[jakarman]

The EGP structure is not public documented by SAS. For the option to build custom task's I also cannot find anything. Just CH blogs and book.

That makes working in the zip-file a tricky approach as all must be done by reverse engineering.

Well I did some of that with reasons. Sometimes you are getting  issue-s and investigating that needed to go into some details.

Examples:

- When you define links to code or datasets you get surprised when it is not working when handed over to somebody else.
  Doing the review research finding that those links are translated to URI's or are base on a personal path not being relative. Those full path are found in the EGP that way.

- Doing the libname task and verify that in the EGP worked. Than changing the appserver to another one, this can cause a hangup of Eguide.

  Finding this worked buggy as the change did not update the information in the egp-file.

Note:

Id did not make any track calls to TS of these examples. reasons: a/ at that moment did not see that as my responsibility  b/ being frustrated by several other TS tracks