Similar to ZCL_ABAK_FORMAT_XML but expects an inline JSON format instead of XML.

Proposed format:

{
  "abak": {
    "name": "Project Z",
    "k": [
      {
        "ricef": "GLOBAL",
        "fieldname": "BUKRS",
        "context": "MAIN",
        "value": "1234"
      },
      {
        "ricef": "PROJZ",
        "fieldname": "WRBTR",
        "v": [
          {
            "sign": "I",
            "option": "EQ",
            "low": "1000"
          },
          {
            "sign": "I",
            "option": "BT",
            "low": "2000",
            "high": "3000"
          }
        ]
      }
    ]
  }
}

Why not serialize ZABAK_K_T directly instead of converting it to ZABAK_XML_K_T first?

There may be a reason but I no longer remember it so I will challenge it.

It would be must simpler. Instead, it returns a string, which is obscure to say the least.

Correcting this would require changing the API but in this case it is probably worth it.

Similar to how it's done in https://docs.abapgit.org/:

Lars explained:

GitHub pages are built and published automatically when there is a push to master, see https://help.github.com/articles/configuring-a-publishing-source-for-github-pages/
And then GitHub also works with Jekyll, see https://help.github.com/articles/using-jekyll-as-a-static-site-generator-with-github-pages/
Its a lot of work to set up the first time, but after that it just works. You can also start out with simple html or markdown which will be published automatically.

_JSON was copied from _XML and both have method CONVERT_XML_K_2_K(). Actually their code is similar except for GET_NAME() and for the transformation id used. So they could probably have a common super class.

For each table found:

• If FIELDNAME has more than one word this is a multi. In this case
  • we need one value per FIELDNAME word
    • OPTION must be EQ
    • SIGN must be I
    • LOW must be filled
    • HIGH cannot be filled
    • INDEX must be 1 (only 1 line allowed because no ranges possible)

What if we want to create constants which are comprised of more than one field? Like:

Currently abaK's API always focus on a single field. Which is the most common scenario and thus should remain the its main focus.

But... would it be possible to extend abaK's functionality to accomplish this without destroying its simplicity and clarity?

Using the synchronized keyword to keep everything in sync with the old descriptions.

Because SET depends on FI module so we'll just drop it.

The only reason for having a specific structure for the XML format is the fact that we can have a simplified value directly in the K node, avoiding the need to create specific K subnodes.

But maybe if a smarter XSLT transformation is used instead of the relatively limited ST... the XML could be directly converted into ZABAK_K structures. This would require creating a KV line every time the value was directly defined in the K node. This would probably also allow for testing if both inline value and V nodes exist and yield an error.

Type "FELDNAM" is unknown.
Type "SETID" is unknown.
Type "TLINE_T" is unknown.

ZCL_ABAK_SOURCE_RFC Unit Test VALID is failing.

I believe the issue is in the content of ZABAK table..
After the latest PULL the content of the table is:

The _DATA class does a lot of checks. These must be covered by unit tests.

To validate JSON content.

IMPORT DIRECTORY INTO itab
FROM DATABASE dbtab(ar) [TO wa] [CLIENT cl] ID id.

Example: SE38 SAPHTML_DEMO_CN

Currently there are two tables with independent data:

• ZABAK_UNITTESTS
• ZABAK_DEMO

Just one table should be enough. Decide on which to keep (probably ZABAK_DEMO) and get rid of the other.

Learn from abapGit

To avoid having to instantiate them in the program.

This is a report (ZABAK_CREATE_TABLE?) which asks:

• Table name
• Table type (Application/customizing/etc)
• If the Maintenance view should be generated
• Function group for the maintenance view
• If it should be registered in ZABAK
• ZABAK: with or without Shared Memory
• Other relevant options?

And then:

• Creates the table with the proper includes
• Creates the maintenance view
• Registers it in ZABAK

It's not exactly the most obvious place to store your constants. But, why not allow it?
https://archive.sap.com/discussions/thread/313580
https://archive.sap.com/discussions/thread/998608

A package for formats, another package for sources, etc.

Currently there are classes ZCL_ABAK_CONTENT_CUSTOM and ZCL_ABAK_FORMAT_CUSTOM. Their sole function is to set GET_TYPE() = CUSTOM. This doesn't do much. So I'll simplify things by getting rid of these.

So, in order to make a new _CONTENT one will inherit from abstract class ZCL_ABAK_CONTENT as all the other _CONTENT classes. And to make a new _FORMAT one will implement interface ZIF_ABAK_FORMAT as all the other _FORMAT classes.

Simpler is better.

Wouldn't it be more consistent to rely on DEMO data for the unit tests?

• Create an autonomous way (report?) to generate the _DEMO data
• Make all unit tests use the DEMO data instead of the UNITTESTS data
• Stop using class ZCL_ABAK_UNIT_TESTS
• Delete class ZCL_ABAK_UNIT_TESTS
• Delete table ZABAK_UNITTESTS

Sets are a good way to store constants. Why not integrate them with abaK also?

They're kind of complex because they allow for hierarchies but it should still be feasible.

I guess it can be called ZCL_ABAK_FORMAT_SET.

The return parameter is of type ZABAK_SOURCE_TYPE which is an internal type associated with a dictionary of a few fixed values. This doesn't make sense. It should either be fixed as CUSTOM or allow for free text.

And the same probably applies to `ZABAK_FORMAT~GET_TYPE() in the case of custom formats.

This is kind of radical at this stage and yet not too late to consider and execute.

The current content flavours are all actually sources of information:

• database;
• file;
• inline;
• rfc
• set
• standard text (SO10)
• url
• mime repository (upcoming)

So it would probably be much more clear to call it what it is.