Throughout that time, software development has generally become more difficult with developers having to learn a wide variety of tools and programming languages, many of which are the hot thing for a short while and then disappear afterwards for the next hot new thing as the cycle repeats.

Up until recently this was not as big a deal for tech companies because they could just hire their way out of the problem. Teams got big and bloated, often because the tools being used were large, complex, rapidly changing and difficult to learn. So the solution, in opposition of the Mythical Man Month, was to throw more people at it. This was feasible because of 0% interest rates and the relative ease of raising capital.

But that era is over. Interest rates are no longer historically low and raising capital for companies is now much harder and less desirable than it once was. This means technology companies are reducing staff and hiring more judiciously. Fewer people now have to do more with less.

The idea of a “one person framework” is that there should be a way for a single developer to create software using just one development framework. This is not a new idea, but it is being talked about again because of these recent changes with how technology companies work. In many ways, Xojo is the original one person framework. From its inception, with inspiration from Visual Basic, Xojo let you make complete apps more efficiently without having to also learn other tools, languages or frameworks.

So what can Xojo, as a one person framework, do for you? Xojo lets you build most of the apps your company is likely to need, using only Xojo itself and its easy-to learn object-oriented programming language (which is similar to Visual Basic and Python, languages that many people already are familiar with). Xojo is a cross-platform, integrated development environment (IDE) that combines an object-oriented programming language, visual designer, code editor, debugger and more into one tool and one framework.

With Xojo you can make apps for most of the commonly used platforms that your business is likely to need.

Desktop Apps

Xojo has been a great way to make desktop apps since its inception in 1998. Unlike Java, Electron or other frameworks you’ve seen throughout the years, Xojo makes native apps and can do so for the major desktop platforms: Windows, macOS and Linux. Yes, that includes native ARM and x86 apps as well.

With a single project, you can click one button to have Xojo build separate native apps for each of those platforms. To further drive that point home, the Xojo IDE itself is a desktop app made with Xojo that runs on Windows, macOS and Linux.

With Xojo you have access to many commonly-used controls and the Xojo framework with support for databases, JSON, XML, RegEx, Zip/Unzip, networking and so much more.

Web Apps

Since 2010, Xojo has been able to make web apps. Xojo uses a somewhat unique approach to web apps by running compiled code on the web server. This code communicates to the app running on the web browser using an internal JavaScript framework and Bootstrap for the UI, which you don’t really need to worry about. It’s all handled automatically.

This approach is great for business purposes as it lets you make web apps using a development pattern that is very similar to what is used to make desktop apps.

If you don’t want to deal with the hassle of managing your own web app server, Xojo even offers Xojo Cloud as a fully managed web hosting service with 1-click deployment of your Xojo web apps.

Mobile Apps

Mobile support first appeared for iOS in 2013 and Android support was recently added in 2023. Using Xojo to make native mobile apps that can be deployed in their respective app stores is yet another way Xojo can help one person make more apps.

A developer that already knows how to use Xojo can jump right into mobile development without having to learn yet another IDE and programming language.

Console Apps

Console apps are text apps that run from the command line. These app are great for automating internal processes or other command-line tools. You can even build Console apps that communicate with other console apps to build a chain of tools for processing or converting data, for example.

Xojo Framework

A single person can create all of the above types of apps because Xojo uses the same programming language for all of them. And as mentioned above, the Xojo framework has many built-in features and is broadly compatible across all the different project types. There are differences, of course, but we strive for consistency and compatibility.

For just a few of its many capabilities, all platforms have the same framework classes and methods for things such as Dictionary, Set, URLConnection, files, SQLite, and most graphics. And speaking of examples, Xojo includes over 400 example projects from which to learn.

Could Xojo Work For You?

As you should now realize, a single developer using Xojo could reasonably create a desktop app (for Windows, macOS and Linux), a web app, and mobile apps for iOS and Android. If you previously had multiple teams of multiple people creating that many apps, then Xojo could really save you a lot of money and time.

Will you use Xojo to make the next Photoshop, FaceBook, Excel or Google Docs clone? Perhaps not, but most companies don’t create those types of apps. Xojo does a lot, but it does not and cannot do everything. There is a limit to what any single framework can do, otherwise it becomes too large for its own good, collapsing under its own weight.

Instead, most businesses have much different needs and often require specially created software. For business apps, especially bespoke small-business apps, Xojo can often be an ideal solution by allowing apps to be created faster, more easily and at less cost than can be done with other tools. This saves you money and time, both of which are in short supply these days.

Xojo is free for learning, development and testing! Give it a spin to see what it can do for you.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The SAP interface has four steps:

1. Determine the path to the SAP library 
2. Build a connection to the SAP system
3. Transfer data to the SAP system
4. Receive data from the SAP system

Connect the SAP System

Your SAP user must have the authority for RFC connections. If so, you must know some data of your SAP logon to connect to an SAP system, such as:

• host name – a name or an IP address (ashost)
• router string 
• system number (sysnr)
• client (client)
• language (lang)
• user (user)
• password (passwd)

At first you must set the path to the SAP libraries. In Windows you have some DLL’s around SAPNWRFC.DLL and on macOS you have some DYLIB’s around LIBSAPNWRFC.DYLIB.

If TargetWin32
  var LibFile as string = "sapnwrfc.dll"
Else
  // get the actual folder and handle the exception
  var MacOsFolder as folderitem = app.ExecutableFile.Parent
  System.EnvironmentVariable("DYLD_LIBRARY_PATH") = MacOsFolder.NativePath
  If System.EnvironmentVariable("DYLD_LIBRARY_PATH") = "" Then
    MessageBox("DYLD_LIBRARY_PATH variable not set")
    return
  end if
  var LibFile as FolderItem = MacOsFolder.Child("libsapnwrfc.dylib")
  var LibPath As String = LibFile.parent.NativePath
  Call RFCModuleMBS.SetCurrentWorkingDirectory(libPath)
EndIf

I’ve copied the SAP libraries with the Xojo build settings into the application resource folders. 

If the setting of the LibPath fails then send the error message:

If not RFCModuleMBS.LoadLibrary(LibFile) Then
  // Failed to load library
  Messagebox RFCModuleMBS.LibraryLoadErrorMessage
  return
End If 

And if the LibPath is set you can do the logon as second step:

var loginParams As New Dictionary
loginParams.Value("ashost") = "12.345.67.89"
loginParams.Value("sysnr")  = "10"
loginParams.Value("client") = "100"
loginParams.Value("user")   = "MYUSERNAME”
loginParams.Value("passwd") = "MyPassword"
loginParams.Value("lang")   = "EN"
var ConnectionToSAP As New RFCConnectionMBS(loginParams) 

Please note if you have a router string you must build the host name (ashost) with a concatenation of router string and host name like this:

loginParams.Value("ashost") = <router string> + "/H/" + <host name>

If the connection fails you will get the reason with:

Exception r As RFCErrorExceptionMBS
 MessageBox r.message 

Calling an SAP Function Module

If you are calling a SAP Function Module you will export key values to SAP and you will receive data or i.e. error messages. To understand the import and export parameters you must look out of the SAP function module in the surrounding world.

This example calls the SAP function module RFC_READ_TABLE. With this standard RFC module you can get the content of a database table and/or the SAP data dictionary description of this table.

Exporting key values to SAP

For exporting the key values to the SAP function module you must load a functions description and create a data container for executing the function module.

var fd as RFCFunctionDescriptionMBS = app.ConnectionToSAP.FunctionDescription("RFC_READ_TABLE")
var f as RFCFunctionMBS = fd.CreateFunction 

The function module RFC_READ_TABLE has two parameters:

• the name of the table as import parameter: QUERY_TABLE
• the select options of the where clause as tables parameter: OPTIONS

f.StringValue("QUERY_TABLE") = "<name of the table>"

var it_OPTIONS as RFCTableMBS = f.TableValue("OPTIONS")
var is_OPTIONS as RFCStructureMBS

is_OPTIONS = it_OPTIONS.AppendNewRow
is_OPTIONS.StringValue("TEXT") = "(MATNR = '4711')" // WHERE clause

You must consider that the maximum length of a where clause for the table OPTIONS is 72 digits. If the where clause length is greater than 72 you must split the clause to several lines. The clause must look like this “(MATNR = ‘1234’ AND WERKS = ‘1000’) OR (MATNR = ‘3456’ AND WERKS = ‘1000’)”. 

And now you can execute the function module into the backend system:

f.invoke

Receiving data from SAP

The function module RFC_READ_TABLE returns now to tables parameters:

• FIELDS – contains the SAP data dictionary description of the returned table
• DATA – contains the data found for the transferred where clauses

TableFields as RFCTableMBS = f.TableValue("FIELDS")
TableData as RFCTableMBS = f.TableValue("DATA") 

If the TableFields.RowCount = 0 then the returned table contains no data. To get the content of a returned table you must loop like this:

If TableData.RowCount > 0 then
  TableData.MoveToFirstRow
End if
For iRow as integer = 1 to TableData.RowCount
  // get a field value
  Var FieldValue as string = TableData.StringValue("<Fieldname in the table record>")
  If iRow < TableData.RowCount then
    TabeData.MoveToNextRow
  End if
next

Error Handling

To catch an exception, you should code into your method something like this:

 Exception r As RFCErrorExceptionMBS
  MessageBox r.message 

Interpretation of Returned Data

If you want to get after the INVOKE the returned data you will have 

• a table or
• a structure or
• a field

If you have a table you will get a certain field with:

Var TableContent as RFCTableMBS
TableContent = f.TableValue("<Name of the returned table parameters>")
If TableContent.RowCount > 0 then
  TableContent.MoveToFirstRow
End if
For iRow as integer = 1 to TableContent.RowCount
  ListBox1.AddRow(TableContent.StringValue("FieldOne"), TableContent.StringValue("FieldTwo"))
  If iRow < TableContent.RowCount then
    TableContent.MoveToNextRow
  End if
Next

If you have a structure you will get a certain field with:

var s As RFCStructureMBS = f.StructureValue("ES_MESSAGE")

TextField1.Value = s.StringValue("FieldOne")

If you have a field you will get the data with:

TextField1.Value = f.StringValue("FieldName")

Using the above techniques with the MBS plugin, your Xojo apps can now access information contained in SAP.

Michael Eckert studied economics from 1982-1986 and has been employed at T-Systems as a software architect since 1989. Michael has worked with ERP systems for 34 years, until 1998 with PL/1, since 1998 with ABAP in SAP R/3 and SAP S/4 HANA. He’s been developing with Xojo for about 9 years.