... XLINK :: new foundation for CodeExchange ...

[Former Member]

Hello all.

I would share with the idea to build a mechanism to combine the strength of standard CTS with SAPLink.

http://www.gmx.de/mc/0ldDlTHK90Lcir8uG580GdBfrrApBi

Regards,

Guido

[gregorw]

Hi Guido,

I think it would be good to extract the essence out of this tread and create a Wiki Page. You could start in the SCN Wiki to allow everyone access.

Best regards

Gregor

[Former Member]

Hello,

I have updatet he presentation concerning the future architecture.

http://www.gmx.de/mc/WK2Bu9IdlXsndWgFsPT9IPzkdwB0Nc

I have renamed the Project to XLinkPlus, because now it offers more than "just" the combination of SAPlink and CTS.

Now it allows to support a producer2consumer software logistic approach which might be also interested for SAP standard products.

All the best & have fun,

Guido

P. S.: Gregor, today my day is fully planned. I will do the wiki page some time next week.

Edited by: Guido Brune on Jan 9, 2011 8:43 AM - typo

[former_member10945]

I'd like to add a bit of color/history to this thread if I might. What SAPlink was built to do was to let developers "share" source code to projects. The ability to examine and use a patch was paramount, in the climate we built SAPlink in there was no way I was going to put some random binary object from some cray internet person onto a DEV machine at my company or even on my own NSP where I had been doing at the time a lot of work. I would have no idea what was in that package and it would just feel like a ticking time bomb.

The idea of automatically activating each object as it came in would have been easy to implement, it was actually harder to get it done in an inactive state, but it was a purposeful design decision to not do that. I wanted the end developer to always be in control of their system, SAPlink was never going to break/overwrite something they had done on their system - ever.

I think the above perspectives still hold true, for what CodeExchange is and how an OSS developer works. In my mind what Guido is suggesting sounds much more like a "installer/packager" then a useful workflow for developers. The idea of passing around a binary object makes much more sense when you are just trying to "install" something and you probably don't care much about how it became what it is. This is not a good workflow for people working on the source code to a project.

Think of a project with two developers. Developer A is working on a object that implements interface Alpha (IAlpha). Developer B is working on an object that also implements IAlpha. Developer A needs to change IAlpha and being a good citizen s/he fixes Developer B's object so the classes can be activated and the unit tests pass. Developer A then checks in his/her changes to IAlpha. Developer B comes to work and grabs the "latest" object. Not being able to see the changes because all the information is binary encoded, Developer B imports the new object. You just ruined Developer B's day, yea their stuff isn't lost but now they have to manually go get the old version and do the resolve, there are much better tools in SCM systems for these activities, one could argue this is WHY SCM exists.

There are tons of other workflows where having only binary object would seriously hamper developers, which is why there are so many SCM systems and why none of them are ever based on a binary object representation.

[Former Member]

Hello Daniel,

thanks for your input!

I phoned Gregor and we are both convined that subversion format have to be XML-based for tracking differences.

I will built a prototype in order to render genrericially an XML based on SOBJ (directory of transportable objects).

All the best,

Guido

[former_member182670]

Hi,

I'll add my 2 cents to the discussion about the representation of the objects.

I agree that binary representation should not be used for already mentioned reasons like version tracking and diff capabilities.

But I think SAPLink representation is just slightly better. XML produced by SAPLink contain a lot of metadata including user names and dates.

The result is that when developer changes single line in a class containing many methods and attributes you cannot easily tell what was changed by looking at the diff. Whole file contains lot of changes which are just noise and don't bring any valuable information.

I think any future implementation should take it into account and provide a more "stable" representation which will not touch and change whole file when making changes.

Tomek

[CarstenKasper]

Hi all,

very interesting thread! I would really appreciate an ABAP client that hooks up to a CVS somewhere in a central repository. It would definatly help a lot with developing in different locations in teams. Furthermore it would be very benefical to spread developments to various systems.

As for the WebDAV I fear I have to agree with Gregor. The BSP_DEV service allows access to the MIME objects. I used it several times to upload graphics, stylesheets or javascript files to our server. It offers no access to other development objects I know of. Please correct me if I am wrong, it would make my life a lot easier

It should not be that hard to write a WebDAV service that is capable of exporting ABAP code and database entries. One for MIMEs and data in the content management is already there.

I am just thinking about putting all developments into one transport request. The service could then scan it an provide access to all those objects. The structure is already defined by SAP this way. Ok, not the XML, but the semantic level.

So much for my thoughts.

cheers Carsten

[Former Member]

Hello,

my idea was also to make a XML represenation of transport request.

Based on a transport request this XML reprentation can be stored in a CVS. On the other hand XML can be converted into a transport request. The corresonding items are in a transport requests. With table are beloning to transport object can be direct read of transport object of TA: SOBJ.

Currently I think the missing piece a converting rountine which allows to convert the XML in the binary format and backwards.

All the best,

Guido

Edited by: Guido Brune on Jan 6, 2011 10:32 PM

[gregorw]

Hi Guido,

what must also be provided is a export for every single object. Otherwise you always have to export all objects of a project to the the Version Management to keep it consistent. SAPLink provides that in the two different export formats:

• Slinkee's are the representation of a single development object like a class, report, data type, structure, table type or database table.

• Nuggets represent a collection of development objects

The developer mainly works with Slinkee's. She/he does a change on a development object, exports that in the case of SubVersion to the local working copy and commits the change to the central repository. Other developers can update their local working copy and import the new Slinkee in their local ABAP system. For consumers who only want to install the project, the Nugget format is provided containing all the needed objects. The main intent of the ZAKE project is exactly to support this process by allowing the automation of export, update, install and build.

Best regards

Gregor

[Former Member]

Hello Gregor,

my idea was to use transport as anchor for the XML represnation.

Mid of december I had already the following OO model:

ZCL_XLINK_BASE

---ZCL_XLINK_TR_REQUEST

---ZCL_XLINK_TR_OBJ

---ZCL_XLINK_TR_DATA

1 Request to many objects to many data

The data itself is stored in stateless XML serializable dataobject which are attribute of ZCL_XLINK_TR_<name> classes.

Additionally there is an expeciton class.

The rendering of transport request into a XML is feasilbe (export), but I have currently on clue how to generate a transport request for the import on target system. One appoarch would to convert the XML into the transport binaries and import them, but how to do if there is no documentation or API on R3-trans (C-Programm).

All the best,

Guido

P. S.: I will post on the transport forum in order insource some input from them.

[gregorw]

Hi Gudio,

do I understand your intended approach correctly and you will create one XML representation for one transport request? As I've explained before that is OK for the distribution of complete projects. But to track the development using a Code Management tool like SubVersion you need a single XML file for each development object. In the ZAKE project I've defined this structure:

<Package Name>
  <Object Type>
    <Object Name>.slnk

Check out the [ZAKE_SVN description|https://cw.sdn.sap.com/cw/docs/DOC-126520].

Best regards

Gregor

[Former Member]

Hello Gregor,

we need to make a milestone plan. I think we can make it in first half of 2011.

I will contact Rui and Oliver how have to push inside SAP.

The MIME Repository is already a WebDAV-Client.

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/46/bb1850ab4811d4968100a0c94260a5/frameset.htm

We have to figure how a future architecture can look like and then give it a try.

Additionally we have to figure the XML schema for XLINK:

<XLINK>

<OBJECTTYPES>

<OBJECTTYP>

<HEADER />

<KEY />

<DATA />

<OBJECTTYP>

</OBJECTTYPES>

</XLINK>

Where <HEADER />, <KEY />, <DATA /> are complex data types.

We have to define how to integrate the whole staff into CTS and WebDAV.

Some work, but I expect the most work on the colloboration part.

All the best,

Guido

[gregorw]

Hi Guido,

 The MIME Repository is already a WebDAV-Client. 

Unfortunately no. The MIME Repository provide a WebDAV Server. I haven't found any function modules or classes that provide a WebDAV Client. Perhaps you're more sucessfull. Give it a try.

Best regards

Gregor

[Former Member]

Hello Gregor,

I found the the package SMIMES contains some funcitionally concerning MIME-Repository.

The class CL_WB_MIME_REPOSITORY looks promsing.

Over this functionally we use MIME Repository as system dependent storage of XLINK based XML representation. From there we can submit to a suvversion server. Is that what do you want?

All the best,

Guido

[gregorw]

Hi Guido,

if we store the files in the MIME repository, on the server or on the client file system isn't the biggest problem. Without a ABAP WebDAV Client we still have to use the way that I'm using in ZAKE_SVN. There I use SVN or TortoiseSVN to handle the communication with the SubVersion repository.

Best regards

Gregor

[Former Member]

Hello Gregor,

thanks for you value input!

I'm not a export on SAPLink, but I understand that is SAPLink has

+ limited suport of object types

+ every object types need to coded manually

+ no package support

+ no activation procedurce

every single is for me a no-go for making ABAP code exchange sucessfull.

I personally think that SAPLink has architecture problem. Additionally the support of object type does not scale.

I want to build something new with a more suitable concept.

Transport files are binaries. The objecttypes are submitted to a C Program which makes the table extract out of the tables and makes the binaries. One approach would be call the C program to make the table extract and wrap it into an XML. But we need support from SAP Basis CTS team to figure out. So XLINK might become a lighthouse for the collobartion between Community and SAP.

All the best,

Guido

P. S.: You also call me. Look at XING to get my current number!

[gregorw]

Hi Guido,

+ limited support of object types

I would argue here: Currently the most needed.

+ every object types need to coded manually

That's a valid point.

+ no package support

Taryck Bensiali has created a [Plugin for the packages (DEVC) |http://code.google.com/p/saplink/issues/detail?id=145&can=1&q=package]

+ no activation procedure

We take care about the activation in the ZAKE project which is intended to automate the complete process.

One approach would be call the C program to make the table extract  and wrap it into an XML. But we need support from SAP Basis CTS  team to figure out. So XLINK might become a lighthouse for the collaboration between Community and SAP. 

Would be great to get the CTS team involved. But sound to me like a long way to go. What we then need in addition would be a ABAP WebDAV Client to replace also the SVN Client I'm currently using to do the SVN checkout / checkin in ZAKE_SVN.

Best regards

Gregor

[gregorw]

Hi Guido,

thank you for starting this discussion now in the real public as the thread in the [Code Exchange project|https://cw.sdn.sap.com/cw/thread/15555?tstart=0] could only be accessed from SCN Users who accepted the Code Exchange Terms of Use. Now every SCN user can join an provide her/his thoughts.

Let me address some of your topics in the concept:

1. Project status [SAPLink|http://code.google.com/p/saplink/] "almost dead"

You're right, the initial developers of SAPLink Dan McWeeney and Ed Herrmann have moved on to other projects. But they made me an owner of the SAPLink and SAPLink Plugins Project in October. What I currently try is to prepare the move to CodeExchange. But with the large backlog of open issues I hope to get help from Andy Singleton to provide a tool which allows at least the migration of Google Code Issues to the Assembla Issue Management. Also I have to get permission from the SAPLink contributors for the license change.

2. SAPLink Object support "limited"

Correct, but I would say: good enough. Every project I'm working on was able to export / import it's development objects. Also large projects like [abap2xlsx|https://cw.sdn.sap.com/cw/groups/abap2xlsx] with currently 6 active contributors working on their own NSP installations are supported well. Now with the WebHooks provided in CodeExchange even an Continuous Build is activated using the tools provided by the [ZAKE|https://cw.sdn.sap.com/cw/groups/zake] project.

3. Why to start yet another ABAP export/import tool?

Are you aware that there is already another competing project called [zaplink|http://code.google.com/p/zaplink/]? I think starting another project should be the last option. Are you also aware of the ABAP in Eclipse project where SAP works on integrating ABAP development in Eclipse? AFAIK the interface to the ABAP Backend system is REST based. I think that could be the future standard solution to integrate with external systems like a SubVersion repository. But that can be years from now to be available on customer systems.

4. Xlink functionality: "Use the standard transport system from SAP"

I've extended the ZAKE project to allow the automatic creation of a SAP transport for the build. We use that in the abap2xlsx project to provide this as an additional installation format for the releases.

5. Xlink functionality: "Build a XML-wrapper around transport files"

I'm not into the details of SAP transport files. But AFAIK they are binary files. The biggest drawback of binary files in a code repository is that you can't use standard tools like diff which can only be used for text files like the XML Format SAPLink provides.

6. Xlink functionality: "Integration into Code-Exchange via Subversion-Support"

Exactly that is the intention of the [ZAKE|https://cw.sdn.sap.com/cw/groups/zake] sub project ZAKE_SVN where the command line SVN Client and TortoiseSVN can be utilized to communicate to a SubVersion Repository out of a ABAP system.

7. Open Points: "We need a support of namespaces"

There is already an open issue on this: [14-provide-namespace-for-abap-projects|https://code.sdn.sap.com/spaces/code-exchange/tickets/14-provide-namespace-for-abap-projects]. Rui is working on a solution. Technically I've decided to use "," in the file names as the replacement character for "/" as this is also used when you create a SAP Shortcut from a transaction in a namespace.

Let me know your feedback.

Best regards

Gregor