Skip to Content
avatar image
Former Member

NW GW Model versioning- use case

Hi All,

I am just exploring the  use of GW Technical model versioning, like can we reuse any existing technical model.

It would be grateful any one can explain the use and the best use case for the Model versioning.

I tried using the existing Model into a different GW Project while the runtime objects generating, and the service builder created the XXX_DPX_EXT with the different version and nothing in it.

I don't what does it  intended to do, and how to use it.



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Sep 12, 2014 at 12:21 PM

    Hi Rajesh,

    We should probably qualify the use of the word 'versioning' because it may get confused with redefinition and redefiniton can be used for versioning!.

    Firstly, you should only be considering versioning of custom services because standard services are in the SAP namespace and any future versioning is in their domain.

    The alternative is to redefine a standard service and attach it to a new 'Z' service definition - from there you can redefine it.

    However, due to the effect of inheritance in all of this, I would only consider versions for true original services developed by customers.

    Contrary to what Ashwin has stated, when you redefine a service, you get all of the DPC and MPC functionality of the original due to inheritance. This makes sense as I would expect a version to be a variant of something existing, otherwise it's a completely new service and needs to be named differently to avoid confusion.

    The basic steps for a version of a Z service are:

    1) Ensure the original service is error free, otherwise you will import the errors into V+1 and will need to delete and restart.

    2) Create a new SEGW project, name doesn't matter too much but probably indicate the version difference in it.

    3) Create the data model using the redefinition option.

    4) Generate the project. When you do this, alter the technical names in the dialog to match the existing original  service and increment the version.

    5) The resulting runtime artifacts should look like this.

    6) Register the service - it will be found with the same name but a new version.

    7) You can now test this service version - it will be identical to the original at this point, unless you dropped any entities/navigations during the redefinition.

    e.g. /sap/opu/odata/sap/ZFOOBAR_SRV;v=2/(etc)

    8) Once happy that you have replicated the original service, you can now define the V+1 DPC or MPC to make the version variations required.

    Some additional points to note.

    • The previous service is still live ( unless you place it out of service). Consumers then have access to legacy versions without needing to immediately upgrade to Vn
    • The ODATA ICF node is shared by the versions, so you cannot turn ICF on/off selectively, etc.

    Hope that helps with your evaluation



    gw.png (34.8 kB)
    gw.png (25.0 kB)
    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Sep 11, 2014 at 10:28 AM

    Hello Rajesh,

    Yes u can reuse the model. If u go to spro u will understand it better.

    Version can be specified by us only at the run-time object generation and i dont see any way we can change/modify the version of an existing model or service.

    When u copy any project in GW service builder, only the model is copied and the implementation has to be done depending on our new use case ( DPC or DPC_EXT class ).



    SPRO.png (15.9 kB)
    Add comment
    10|10000 characters needed characters exceeded