Names are not saved in portal for EPML models

[GoogleCodeExporter]

Export(save and save as) works fine but portal doesnt keep the name and process 
version of EPMLs. so you will see a process with no name added to the end of 
the list after saving.

Original issue reported on code.google.com by mehrad1@gmail.com on 25 Mar 2011 at 5:53

[GoogleCodeExporter]

epml xsd does not define element to associate to epml process its name, id, 
creation date, owner, etc as it is for xpdl processes.

My question concerns the best way to extend epml description so it is possible 
to store these data in xml native processes:

1 - add corresponding xschema specifications in EPML_2.0.xsd and generate the 
associated java classes with jaxb

2 - modify directly the java classes

The first solution seems to me to be the less worse...

What do you think? 

Original comment by macri.fa...@gmail.com on 28 Mar 2011 at 1:21

[GoogleCodeExporter]

Definitely for option 1. I think we already discussed this with Abdul and Marie 
and identified how an EPML file could be extended without violating the schema 
in order to incorporate this information. Please note that this information 
will not be available when we import a native EPML 1.2 or EPML 2.0 file. In 
this case, should we ask the user to add this information?

Original comment by marcello...@gmail.com on 28 Mar 2011 at 10:57

[GoogleCodeExporter]

Issue 128 has been merged into this issue.

Original comment by marcello...@gmail.com on 30 Mar 2011 at 8:30

[GoogleCodeExporter]

Actually, we have decided not to extend the schemas of the native formats, but 
to do as follows:

Scenario: Importing a native file.
We check if this file contains the meta-data we are interested in and we fill 
out all fields that can be populated with the existing information in the 
native file. For example, XPDL *may* provide this information, however we 
cannot assume that all tools that create an XPDL file will fill out all this 
information (e.g. BizAgi may not store the Author name while some other tool 
may not store the Domain name or version). Similarly, when we import an EPML we 
would probably only be able to retrieve (at most) name and creation date, 
leaving all other fields black. Some of these fields are mandatory and so if 
empty we ask the user who is importing the model to fill them out (e.g. I must 
assign a name but I may leave the domain blank). Once the file has been 
imported, the meta-data will be stored in the canonical format (note that in 
the future we will store canonical formats as a relational schema, so directly 
in the DB).

Scenario: Editing an existing model 
When one decides to edit a model, Apromore will take the content of the model 
either from the native format (if the native format is already available in 
Apromore) or will convert it from Apromore. Moreover, it will take the 
meta-data information associated with that model from the canonical format. 
This meta-data will be wrapped in the message to be sent to Oryx together with 
the content. In this way we don't care if the meta-data was contained in the 
native format.

Scenario: Saving or Saving as a model from Oryx 
When saving (as) a model in Oryx, Oryx will pass the content of the model in a 
message to Apromore, together with the meta-data, like modification-date and 
version number. Upon receiving this information, Apromore will convert the 
content into the canonical format and add the meta-data retrieved from the 
message. Essentially this scenario is similar to Importing, with the only 
difference that the meta-data is *always* taken from the Oryx message rather 
than from a user dialog/native format.

This has implications for the Apromore, which needs to wrap this meta-data in 
the messages sent to Oryx, and be able to retrieve this information from the 
messages sent by Oryx. 

This also has implications for Oryx which needs to retrieve and store this 
information in the messages from/to Apromore.

Original comment by marcello...@gmail.com on 30 Mar 2011 at 8:32

• Changed state: Started

[GoogleCodeExporter]

This a list of things that need to be done to fix this issue:

- Modify EditSession data structure (sent by Portal under Oryx request): as we 
do no longer rely on native formats to store some meta-data, this data 
structure should contain all of them: process name, version name, owner, native 
type, domain, creation date, last update (when applicable), annotation (when 
applicable), withAnnotation

This modification impacts Oryx and all apromore services

- Modify operation ReadNative offered by Portal: should return npf and all 
meta-data

- Modify operation WriteProcess (called by Oryx request "save"): 
WriteProcessInputMsg should also contain the new version name (all other 
meta-data will be found in EditSession)

- Modify operation WriteNewProcess (called by Oryx, request "save as"): if we 
assume that owner, native type and domain are inherited from the original model 
WriteNewProcessInputMsg must contain all others.

- GUI for importing a model has to be revisited as explained by Marcello in 
previous comment.

Original comment by macri.fa...@gmail.com on 27 Apr 2011 at 7:01