In my previous installment, I ended off by promising that I would post details of a search front-end for the ABAP source code index as an ABAP program. That was four months ago, so I guess it is high time I made good on my promise.
If you have been a long time reader of my blog, you may think I have a bee in my bonnet about being able to search through ABAP source code, as if it were some holy grail or something. Yet when I consider that, given the following use cases, I think there is a lot of scope for such a solution:
In a corporate environment, where there is the convenience of face-to-face exchange, and immediate discourse through means such as telephone or meetings, much information goes lost, leading to the large overhead of getting new members on the same page as everyone else.
Following my previous post, where I showed a solution for translating JSON to an ABAP data structure, I am just posting an example of a class that will allow you to do both (ABAP to JSON and vice versa).
On my current project, I had to write some ABAP code to convert a (deep) ABAP structure to JSON. I have seen at least two projects out there that do the same thing, but nothing that converts JSON to ABAP. So I set out to produce an ABAP program to do this.
I have just started a project on GitHub for a library that I am writing which wraps the NW RFC SDK library using Ruby-FFI.
Having worked with ABAP most of my career, I have not had to care a lot (if ever) about Unicode, maybe due to the fact that I work in a country where all SAP systems only use English (with very, very rare exceptions).
While I was working in Javascript extensively for a project, one of the things I really liked about it was how you could use the dot notation to access members of an object, just as you would call methods. After that, I would often find myself in an IRB shell, absent-mindedly trying to do the same thing with a Ruby Hash, only to be thrown a NoMethodError. The first reaction might be: “Ah, if only Ruby had this feature like Javascript does.”, but of course, it can!
In this article, I investigate the possibility of developing a URL-based API for the Business Object Layer (BOL) that could be used to develop an alternative to the standard CRM Web UI.
I was going to title this post “Three days, three distros” or “Three distros in three days”, but that is not half as captivating. Indeed, as the would-be titles suggest, this is about switching distros (again). After running for a while on Linux Mint 10, I decided it is time to upgrade.
Powered by sciolism 2019 and WordPress.