Editorial – Elevate 2018 Report

Editorial – Elevate 2018 Report
- Written by Bruce Armstrong 

Summary

This was the second time that Appeon had hosted a PowerBuilder user conference on their own, and once again I thought it went extremely well, even better than the prior year.  As with the prior year, attendance was good and quite diverse.

Facility

The conference was held in the Sheraton Philadelphia Society Hill Hotel.  As it is a hotel and in a popular area with a number of other hotels nearby, there was no need for Appeon to provide transportation to and from the conference location as was required last year. 

The meeting area was divided into four sections as highlighted in orange below:  A&B (A1, A2 and B all combined), C, D and E (E1 and E2 combined).  The keynotes were given in A&B and sessions were running concurrently in A&B, C, D and E.  Breakfasts were provided in the Ballroom Foyer and lunches in the Hamilton Room.

Read More
  285 Hits
  2 Comments
285 Hits
2 Comments

Elevate 2018 – Annual PowerBuilder Conference Last Call

Elevate 2018 – Annual PowerBuilder Conference Last Call

This years Elevate 2018 Conference is now fast approaching so it is time to register to benefit from the significant amount of technical sessions scheduled.  The technical sessions should be of interest no matter you are primarily maintaining an app or looking to elevate your apps to the next level. The conference itself this year is scheduled for November 5-7, 2018 in Philadelphia at the Sheraton Philadelphia Society Hill Hotel, and your registration fee covers the 60+ hours of technical sessions, breakfasts and lunches, and admission to a special evening networking event.

The conference will start out with an information-packed keynote address that will cover many exciting items about PB 2017 R3, the upcoming PB 2018, and the latest updates to the product roadmap. The keynote will also address the new C# features of PB 2018 with valuable information, such as: 

How PowerBuilder 2018 fits in the .NET ecosystem?How PowerBuilder 2018 takes your apps to the cloud?How will PowerBuilder modernize the UI of your apps?What are the latest updates to the PowerBuilder roadmap?

Many technical sessions are planned related to the key features and technologies of PB 2018 such as:  .NET Core framework direction, n-tier REST based architecture, the new C# DataStore/ModelMapper, and so on. Following the keynote address, various daily technical sessions will commence focusing on hot topic areas such as: C# with PowerBuilder, Modernizing your UI/UX, Cloudify Existing App, Integration, Design & Best Practices, and Development Productivity. In between these sessions, you will be able to schedule time to meet one-on-one with the Appeon Product Team or Appeon staff to discuss your specific project questions or challenges.

Building on the excellent feedback from last years Elevate 2017 conference, you will be excited to hear that many of last years presenters will also be returning to Elevate 2018 to present fresh new topics for this year. On the Appeon side, the Elevate 2018 conference will also have the pleasure of key people from the Appeon Product Team, including Appeon CTO John Qi and Appeon product manager Julie Jiang, and of course other Appeon staff. Many of the returning conference presenters are also well-known Appeon MVPs such as: Bruce Armstrong, Marco Meoni, Michael Kramer, and Matt Balent, just to mention a few. There will also be a host of presentations from real-life Appeon customers who will educate you how they overcame project challenges or used new features of PowerBuilder.

The daily agenda will start with a continental breakfast at 8:00am followed by Education Sessions from 9:00am to 12:00pm, where afterwards lunch will be served. Following lunch, the Education Sessions will continue from 1:00pm through until 5:00pm. On the last day, the Education Sessions will conclude earlier at 3:00pm for those wanting to catch an early flight or drive back home.

Read More
  570 Hits
  4 Comments
570 Hits
4 Comments

PowerServer Web for PB 2017 R3

PowerServer Web for PB 2017 R3

PowerBuilder 2017 R3 contains a pleasant surprise for the PowerBuilder Universal Edition customers. Prior to this release of PowerBuilder, the Universal Edition included the PowerServer Mobile edition only. This meant that the developers were restricted to the building mobile (iOS and Android) apps only unless they purchased developer licenses of PowerServer. Beginning in R3 though, Appeon has now included both the PowerServer Mobile and Web development licenses (for .NET) within the Universal Edition installation. This now means that the PowerServer Toolkit, which is utilized from within the PowerBuilder IDE, can be used to also deploy PowerBuilder projects as Web apps to the provided development-use PowerServer, as follows:

Figure 1- PowerServer Toolkit project for Web and Mobile deployment       

Aside from being able to convert existing projects to Web apps, another “hidden gem” that is included in PowerServer Web is a feature known as Installable Web Applications (IWA).  IWA takes advantage of your application being web-deployable but replaces the Web browser with its own container known as the IWA Runner. The IWA Runner removes the dependency on the Web browser, including dependency on its configuration and permissions to install the web browser plugin.  This makes it even easier and more seamless to deploy PowerServer Web apps to users. You get the same benefits of running in a Web browser, but you can access your apps like a typical desktop application. Specifically, IWA installs your web-based application as a Windows short-cut on the user’s machine. When the application user selects the application short-cut, the PowerServer Web application is downloaded just-in-time (JIT) to the client machine and executed.  

Figure 2- Actual IWA application short-cut

Read More
  1740 Hits
  8 Comments
1740 Hits
8 Comments

Appeon CodeXchange

Appeon CodeXchange

 Appeon has now fully resurrected the CodeXchange side of PowerBuilder-related resources for the developer community under the new Appeon Community website. Previously, the CodeXchange code samples were loosely housed underneath the main Appeon Website and “read-only”, which was not conducive for expanding the code examples, exchanging ideas about a particular code sample, or easily find code samples of interest. These limitations have now been addressed by housing the CodeXchange under the new Appeon Community website, as follows:

 

The new CodeXchange home allows for a much better code sample navigation and searching experience.  It is better structured around the programming language and deployment targets you are interested in. It is easy to see if there are any new items and when the most recent activity occurred.  You also have an advanced search functionality by clicking the “Search Code” button, as follows:

Figure 1- Advanced Search

When viewing a particular code sample, the new CodeXchange area now allows you to interact with the author and fellow developers. You can exchange ideas about or discuss the code sample by posting a reply.  For example, you may want to ask the author a question or you may have suggestions for other Appeon Community users how to benefit from this code sample.  And you can easily share the code sample with anybody by using the various sharing options, such as: email, Twitter, Facebook, Google, etc. interactions, as follows:

Read More
  306 Hits
  1 Comment
306 Hits
1 Comment

Enhanced HTTP Security for PB2017R3 – OAuth 2.0

Enhanced HTTP Security 
for PB2017R3 – OAuth 2.0

PowerBuilder 2017 R2, released in January 2018, added TLS 1.2 support in the new HTTP Client and RESTful Client components. Both objects have a property named SecureProtocol that can be set to a value of five (5) to ensure only TLS 1.2 protocol is utilized. TLS 1.2 takes advantage of the use of the higher SHA-256 encryption standard and the client and server’s ability to specify the accepted hash and signature algorithms. TLS 1.2 also supports authenticated encryption, TLS extensions, and AES cipher suites.

PowerBuilder 2017 R3, released in July 2018, upgrades PowerBuilder to support the new OAuth 2.0 specification – often just commonly referred to as OAuth2. With the inclusion of OAuth2 features, application developers and their resulting applications can take advantage of the security features of OAuth2.  Before the average developer utilizes the new OAuth2 features of PowerBuilder, it helps if you understand the concepts behind the OAuth2 implementation.

OAuth2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service.  Many popular third-party HTTP services use OAuth2, such as GitHub, Google, Facebook, etc. – just to name a few.  OAuth2 works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access that user account. The OAuth2 system provides authorization flows for web, mobile and desktop applications. It does this by using four OAuth2 roles, which are: Resource Owner, Client, Resource Server and Authorization Server. The OAuth2 framework defines these roles as:

Resource Owner is the user who authorizes an application to access their account.Resource Server is the server hosting protected data (for example Google hosting your profile and personal information).Client is any application requesting access to a resource server. Before it may do so though, it must be authorized by the user, and the authorization must be validated.Authorization Server is a server issuing access token to the client. This token will be used for the client to request the resource server. This server can be the same as the authorization server (same physical server and same application) as this is often the case.

 

High Level Flow

Read More
  434 Hits
  4 Comments
434 Hits
4 Comments

Enhanced Source Code Control for PB2017 R2/R3

Enhanced Source Code Control
for PB2017 R2/R3

PowerBuilder R2, released in January 2018, added native support for both the Git and SVN (Subversion) source code control (SCC) software. This native support, where PowerBuilder interfaces directly with these popular SCC systems using their native APIs, allowed PowerBuilder to support more SCC features as well as realize much faster SCC performance and reliability. SCC can be accomplished without requiring the TortoiseGit and TortoiseSVN client software, but to get the full benefits of Git or SVN we recommend installing and using the appropriate Tortoise client software.

PowerBuilder 2017 R3, scheduled to release in the summer of 2018, adds support for additional native APIs of Git and SVN (i.e. more SCC features in PowerBuilder) as well as some usability enhancements. The new features and enhancements include: difference comparison, logging, locking (SVN only, but this is not really needed for Git – more on that in a future blog), support for OrcaScript compiles via Git/SVN, and no longer needing the PBG file (PB’s legacy SCC mechanism). These new SCC features and usability enhancements greatly improve developer productivity when using PowerBuilder with Git or SVN.

It worthwhile to point out that Git and SVN are not the same SCC architectural wise. In a nutshell, Git architecture is based on a distributed approach while the SVN architecture is based on a traditional centralized approach. While both Git and SVN overlap in solving SCC problems, there architectural differences poses trade-offs. A centralized approach like SVN can make administration of the SCC much easier to manage versus Git, but at the cost of some developer productivity and flexibility.

On the other hand, Git allows multiple developers to work on the same object, branching and rewriting history, and offline development, just to name a few of its highlights. However, this comes at the expense of having to merge changes across local developer repositories due to its distributed nature, which under most circumstances TortoiseGit can automatically resolve for you should it happen.

Git is the source code version control system that is rapidly becoming the standard for Microsoft as well as many public (e.g. open source) projects. This was highlighted in 2018 with Microsoft’s acquisition of GitHub.  Also, a number of other popular SCC systems now support using Git as the SCC repository.  In fact, the default configuration now for TFS is using Git (rather than TFVC) as its repository.

Read More
  763 Hits
  0 Comments
763 Hits
0 Comments

PowerBuilder’s HTTP Client Evolution

PowerBuilder’s HTTP Client Evolution

PowerBuilder’s prowess to be able to enable Win32 and Win64 native applications to directly interact with the Internet universe started when Sybase added the iNet object class to the PowerBuilder System Class area.  The iNet object object’s methods allowed native PB apps to link out to a specific URL via the LinkToURL command, send data to a specific URL via the PostURL command and/or read data from a URL via the GetURL command. While this is still in PowerBuilder 2017 R2 for backwards compatibility, its functionality limitations and security vulnerabilities (only supports up to TLS 1.1) definitely makes it worthwhile to explore the new HTTPClient object, which we will discuss in this blog.

Figure 1- iNet object as seen in the PB IDE's Object Browser

 

In modern-day Internet interactions, applications often require more advanced functionality within their URL processing and support for at least the TLS 1.2 protocol is a must. Thus, starting in PB 2017 R2, Appeon added the HTTPClient object to the PowerBuilder’s System Class area. The HTTPClient object is designed to take over from the iNet object and to provide key advanced features that were requested of the iNet object even way back in the Sybase days of PowerBuilder but were never implemented. Some of these key advanced Internet features requests were to: set Request Header(s), read a Response object’s Header or Body, get the Response Code from a Request, process binary data, handle JSON data, and of course support TLS 1.2.

You may be wondering why Appeon didn’t just enhance the iNet object?  One of the key reasons for introducing a new HTTPClient object class rather than revamping the existing iNet object was to avoid iNet object class behavioral changes that could break existing apps when migrating to newer PowerBuilder releases. The other key reason was an entirely new implementation was necessary so that the RESTClient object (covered in another blog) could make use of the HTTPClient.  This was important design consideration by Appeon such that PowerBuilder would have a modularized and extensible architecture.

Read More
  398 Hits
  1 Comment
398 Hits
1 Comment

PowerBuilder’s SOAP to RESTful Evolution

PowerBuilder’s SOAP to RESTful Evolution

The movement from SOAP-based web services towards RESTful-based web services is another evolutionary journey for PowerBuilder developers and their related applications. Originally, Sybase added SOAP (Simple Object Access Protocol)-based features in PowerBuilder version 8.0. The original SOAP features were aligned with the Java implementation of EasySOAP and provided a messaging protocol specification for exchanging structured information in the implementation of web services across computer networks. Sybase enhanced the web service feature in PowerBuilder version 9.0 to include the ability to handle more complex SOAP interactions. In PowerBuilder version 11.0, Sybase then added support for Microsoft’s .NET-based web service framework as well. This greatly improved the web service interaction possibilities in that era of PowerBuilder. The .NET web service feature was tweaked again in PowerBuilder version 11.5 (and latter PowerBuilder versions) to support the newer releases of the .NET framework.

Since PowerBuilder 11.5 though, the basic SOAP-based architecture has been PowerBuilder’s “go to” vehicle for web service interactions. However, the IT industry moved onward with newer REST (Representational State Transfer) web service technology, which has now become a de facto architectural style used by most modern web services. The REST approach defines a set of constraints and properties based on the HTTP protocol that provides greater interoperability between computer systems on the Internet today. By REST using a stateless protocol and standard operations, REST systems can have faster performance, reliability, and the ability to grow, by re-using components that can be managed and updated without affecting the system, even while it is running.

There are six guiding constraints that define a RESTful system. These constraints restrict the ways that the server may process and respond to client requests so that, by operating within these constraints, the service gains performance, scalability, simplicity, modifiability, visibility, portability, and reliability. If a service violates any of the required constraints, it cannot be considered RESTful. The formal REST constraints are as follows:

Client–server architectureStatelessnessCache-abilityLayered systemCode on demandUniform interface

The focus of a RESTful service is on resources and how to provide access to these resources. A resource can easily be thought of as an object as in OOP (object-oriented programming). A resource can consist of other embedded resources as well. While designing a system, the first thing to do is identify the resources and determine how they are related to each other. This is like the first steps of designing a database: identify entities and relations. Once we have identified our resources, the next thing we need is to find a way to represent these resources in our system. You can use any format for representing the resources, as REST does not put a restriction on the format of a representation.

The client and service talk to each other via messages. Clients send a request to the server, and the server replies with a response. Apart from the actual data, these messages also contain some metadata about the message. It is important to have some background about the HTTP request and response formats for designing RESTful Web services. REST requires each resource to have at least one URI (Uniform Resource Identifier). A RESTful service uses a directory hierarchy like human readable URIs to address its resources. The job of a URI is to identify a resource or a collection of resources. The actual operation is determined by an HTTP verb. The URI should not say anything about the operation or action. This enables us to call the same URI with different HTTP verbs to perform different operations.

Read More
  457 Hits
  1 Comment
457 Hits
1 Comment

Base64 – Your New Binary Friend

Base64 – Your New Binary Friend

PowerBuilder’s Web Service prowess has increased significantly in recent releases from Appeon - in particular, PB2017 R2 and R3 release. These PowerBuilder releases have given us a new HTTP Client and RESTful Client capabilities that can utilize the newer JSON (JavaScript Object Notation) data format and the ever-popular XML (Extensible Markup Language) data format as well. When processing standard data type information in either the JSON or XML format, the ease of data exchange is very high. However, when trying to transfer binary data, the JSON and XML formats and the supporting HTTP transport layer for RESTful web services will not readily handle binary data.

To address this binary dilemma in the JSON and XML realm, today’s applications utilize the Base64 binary-to-text encoding mechanism to convert binary data into ASCII text sequences of the data. This allows the converted data to be injected into the JSON or XML schema and transmitted without upsetting the HTTP transport protocol. While it does increase the overall transmission data length when utilizing this encoding scheme, it is necessary in order to achieve the end goal of data exchange with these technologies.

In PB2017 R3, PowerBuilder will be updated to include new functions to both encode and decode binary data to and from the Base64 encoding scheme. The new PB built-in Base64Encode and Base64Decode commands can now perform the encoding in and out of the Base64 scheme using the standard PowerBuilder run-time engine support. For example, the PB Base64 PNG image used in this article would look like the following in a hexadecimal editor:

Figure 1- PowerBuilder Base64 Image in Hex

Using the new built-in Base64Encode method, the PNG image binary data is converted into a set of ASCII character sequences which can now be easily transmitted or even read by a simple text editor, as follows:

Read More
  350 Hits
  0 Comments
350 Hits
0 Comments

PowerBuilder’s PDF Evolution

PowerBuilder’s PDF Evolution

 

 

 PowerBuilder’s prowess to be able to create Portable Document Format (PDF), has been supported for a long time in the product’s history.  PDF documents have become the gold standard for delivering information, especially in the form of reports. PowerBuilder’s PDF generation capabilities are as follows (in historical order of their introduction):

External DLL – third party solutions that can be called via PB external method declarations in the early days of PB.XLSFO (Extensible Stylesheet Language Formatting Objects) - a Java-based solution included with the PB run-time and supported by the DataWindow, which was introduced in PB 7.PostScript Printer – third party printer solutions that do not require a PB interface but only require a PB app to print to an MS-Windows installed printer.GhostScript – an open source solution that PB can utilize via a specially installed printer definition named “Sybase DataWindow PS”, which was introduced in PB 9.NativePDF – a built-in PDF solution (i.e. doesn’t require separate licensing or installation of third-party solutions), which was introduced in PB 2017.

All the above PDF generation mechanisms are still in place today (for backwards compatibility) in PB 2017. However, it is important to understand the advantages and disadvantages of these PDF generation mechanisms and use the appropriate one for your project, especially considering the enhancements made to the NativePDF option in the upcoming PB 2017 R3 release. In this blog, we’ll attempt to get a better perspective on these PDF options.

A variety of external PDF solutions exists for PowerBuilder and are commonly used in many existing projects. However, they often come with a significant extra price tag. They also come with the requirement to define external functions and maintain PowerScript code to support the external connectivity. Since these are developed and maintained by third party vendors, if you chose an unreliable vendor or the vendor ceases to continue the product then to move to a new vendor’s product usually will require a significant re-programming effort.  On the plus side, if you choose a good third-party product, it produces a high-quality rendering and supports advanced PDF features.

Read More
  849 Hits
  1 Comment
849 Hits
1 Comment