abapGit/abapGit-Plugins

SOBJ Grocery list

Closed this issue · 4 comments

  • test transports

will TR_TADIR_INTERFACE make sure to add the object to a transport if needed. To be tested

  • language support

abapGit currently only serializes english texts from text tables. Dont want to load texts into a system with a language that is not enabled in the system. Been wondering to create language add-on "packages" like standard do.

  • usernames in serialized files

usernames and timestamps are cleared in seralized files, for privacy reasons and to make sure the person that imported the object into the system is the responsible person in the target system

  • activation/worklist

does some of the objects need to be added to the SE80 worklist, and or activated

  • lcx_obj_exception needed? just raise zcx_abapgit_object
  • add origin in XML

If for some reason in the future some objects are implemented with API calls instead it could be nice to know if the serialized object originates from the generic solution.

  • CALL TRANSFORMATION handling of new/removed fields

from testing in https://github.com/larshp/abapGit-NextGen-XML it looks like it handles it automagically

Imho, ABAPGit as well as SAPLink are deployment mechanisms that should behave as similar as possible compared to the well-known deployment on ABAP: The TMS.
This is also the origin idea of using the SOBJ: TMS effectively operates similarly.
Therefore, I disagree to some features you wanted to purchase ;)

transport-connection

Imho, this should not be enabled within the plugin, but within the report. TR_TADIR_INTERFACE only creates the TADIR. Proper APIs for creating a model entity usually handle this. TR_CORR_INSERT is an interface to the TMS, but not necessary to get the object to life.

languages

I would consider it a bug if not all languages were exported. Enabling a language in a system (of the same codepage, of course) is something which might be done after an import.
Also, cooperation with other developers might be seriously affected if multiple developers don't share a language ;)

Administrative data

Also here: I compare that to a transport: No data is manipulated there as well. Again, when working with multiple developers on one object, this would cause permanent differences.
However, I could imagine to offer an option on pull take ownership. Might be a bit tricky to implement properly though...

Activation & Worklist

I execute the AFTER_IMPORT-Method. This should perform the usual activation steps necessary, just like in the TMS. TMS and WB are quite separate worlds, I can't see a reason why this should be necessary

lcx_obj_exception

I wanted to have an own exception type to be able to use the same code also for SAPLink. For the same reason, I also created a lif for the container.

Metadata of the serlialization

I also thought of that and even implemented it earlier. However I deleted it for two reasons:

  1. The metadata should also feature an export timestamp, version and alike. However, as the serialization is also invoked when comparing between repo and local, this leads to permanent commit options. =>
  2. This should be handled in lcl_objects. Then, the format can be decided centrally as well as the element can be ignored on comparison for pull/commit.

New fields and ID-transformation

I can't imagine this being so tolerant. Also serializing a char10 into a char20 results in a shortdump. Therefore, I implemented all the hassle with creating structures according to the origin field-catalog.

Lets move the language issue to abapGit/abapGit#182

Lets figure out the TRANSFORMATION stuff, as it is important for both SOBJ and
https://github.com/larshp/abapGit-NextGen-XML

I've added a few more unit tests, see:
https://github.com/larshp/abapGit-NextGen-XML/blob/master/zxml.abap#L509
https://github.com/larshp/abapGit-NextGen-XML/blob/master/zxml.abap#L539

I've fixed the unit test examples, all seems to work

closing issue