I guess, this is quite a common topic but I haven't been able to find sufficient info on the web. In the context of setting up our SOA governance (processes + tooling), we also need to migrate all decentralised service informations and meta data into WSRR.
There is a couple of pointers on loading WSDL documents and thereby generating the logical service model (Service, ServicePort, ServiceInterface etc.) using the document shredding facility. But I can't find anything on automatically generating governance artefacts and metadata (CapabilityVersion, SLA, SLD).
I am referring to the entities within the SOA Governance Layer (SLA, SLD) and Technical Asset Governance Layer (Capability Version, Service Interface Spec, SchemaSpec) as well as the relationships upstream to the Business Asset Governance Layer (Business Capability, DOU, Charter) and downstream to the Service Model.
Please refer to the GEP63ArchitectureModel within the GEP63 Business Model Package in WSRR studio.
This topic has been locked.
3 replies Latest Post - 2012-12-10T09:11:53Z by John_Colgrave
Pinned topic Data migration excel/csv --> WSRR v8 for GEP metadata
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-12-10T09:11:53Z at 2012-12-10T09:11:53Z by John_Colgrave
DavidSeager 110000C5XS47 PostsACCEPTED ANSWER
Re: Data migration excel/csv --> WSRR v8 for GEP metadata2012-12-05T09:41:07Z in response to NickLaquaThe entities you talk about (SLD etc) are not automatically generated. These are created as part of the process of pushing services through our governance life cycles.
I know other clients have had to import existing services and their contracts into WSRR, unfortunately this is a manual process with the out of the box WSRR.
WSRR does offer several APIs (REST, Web Service, EJB) which you could use to code against to create your SLA, SLDs etc, if you have the information about which service relates to which elsewhere.
NickLaqua 060000RSNW17 PostsACCEPTED ANSWER
Re: Data migration excel/csv --> WSRR v8 for GEP metadata2012-12-10T08:17:02Z in response to DavidSeagerI guess, there is two topics here.
the first issue is the generation of entities above the service model. I already realised that there is no "out of the box" migration support. Probably because the metamodel can be tweaked so much, the migration/data loading support would have to be as flexible. So, API access seems to be the way to go.
the second issue are the lifecycles. I am assuming that when generating entities programmatically (capability version, SLA, SLD), these will automatically enter the governance lifecycle entering the "identified" state rather than being listed as "in production".
In order to overcome this issue, would it be feasible to generate a "initial load" lifecycle which would automatically move these entities into the "production" state (still applying relevant governance policies) ?
If yes, what would be the right way to do that (temporarily disable GEP lifecycles), and are there any traps (e.g. different namespaces between migration lifecycle and GEP lifecycle) ?
John_Colgrave 120000E4PG8 PostsACCEPTED ANSWER
Re: Data migration excel/csv --> WSRR v8 for GEP metadata2012-12-10T09:11:53Z in response to NickLaquaYou could also investigate using the WSRR configurable modifier to automate the creation of at least some things such as an SLD and a CapabilityVersion in response to something like a WSDL being loaded. I am not sure if you would have enough information available to automate the creation of an SLA and link it to the correct SLD.
The configurable modifier is what is used to govern an object when it is created so if you really want to move things to the "production" state then you could either automate the normal transitions to get to that state, if you can satisfy all of the governance policies of those transitions, or you could add a new transition directly to the production state and perhaps restrict the use of that transition to a particular role.
I am pretty sure that creating a different lifecycle would not work as the states and transitions would have different URIs from those in the default GEP.