Git Enhancements in PowerBuilder 2017 R3

Support for using Git as a source control system without going through a bridge product was added in 2017 R2 and covered in a previous blog post.  In this blog post we're going to look at the enhancements that were added to that feature in 2017 R3. 

JSON Enhancements in PowerBuilder 2017 R3

There were some JSON features introduced in 2017 R2, in particular the JSONGenerator and JSONParser, which were covered in a previous blog post.  2017 R3 introduces additional important JSON features, in particular JSON import/export from a DataWindow, and a JSONPackage object that is used to merge/extract JSON data sets.  Those will be covered in this blog post.

PowerBuilder 2017 R2 New Feature: REST

One of the new features added to PowerBuilder 2017 R2 is support for REST web services.  This feature isn't 100% complete, as additional REST functionality is planned for 2017 R3.  There's still a lot in the R2 release to look at though.

To make things simple for the demo, we're going to use a online REST web service called JSONPlaceHolder..  The service doesn't require creating an account or user authentication.  While the GET (retrieve) methods are fully functional the POST ( insert ), PUT/PATCH ( update ) and DELETE (delete) methods are placeholders.  They return result codes or in the case of POST the id value of the inserted row, but they don't actually modify the data.

Note that while REST web services can return data in any internet mime encodable format, the vast majority of them use JSON  and JSON is the only data format supported by the REST client object in PowerBuilder 2017.

Exporting Datawindows to Excel / Html without losing Format

I have a function called "GuardarAExcel2()" which uses a step datawindow called "d_filafichero". With this function you generate an excel with the same visual aspect as your datawindow. I hope it helps you:

Example of use:

GuardarAExcel2( dw_1, "c:\Report.xls")
GuardarAExcel2( dw_1, "c:\Report.html")

Result in datawindow:

PowerBuilder 2017 R2 New Feature: Git source control support

In a previous blog article we looked at the new feature of PowerBuilder 2017 R2 for Subversion source control support. In this blog article we're going to look at a very similar feature, Git source control support.  I'm not going to go through the history of source code support in PowerBuilder again, I'd refer you to that previous blog article for that.  We're going dive straight in to how the Git feature works.

Setting up Git

For this demo, we're going to use Bonobo Git Server.  One reason I like it is because it provide a web based admin console for managing the server, so I don't have to use the Git command line to do that.

Because it's an ASP.Net application, the machine where we're going to install it must have IIS and the .Net Framework 4.6 installed on it.  To install Bonobo Git once you've downloaded it you simply need to:

PowerBuilder 2017 R2 New Feature: Subversion (SVN) source control support

PowerBuilder's initial support for version control systems required drivers for specific vendors (e.g., PVCS) and often for specific versions of that vendor's products.  It was not unusual to find that you needed to wait to upgrade your source control product until PowerBuilder released an updated driver for it.  And if your source control provider wasn't supported by PowerBuilder you were simply out of luck.

That changed with PowerBuilder 6.  With that release, PowerBuilder abandoned the vendor specific drivers in favor of the recently introduced Microsoft Source Code Control Interface (MSSCCI).  Essentially an ODBC for version control, it freed the IDE from vendor lock-in.  Provide the source control provide provides an MSSCCI complaint interface, or there was a 'bridge' product available that could convert MSSCCI calls into the source control providers native API calls, PowerBuilder could use the product.

Using PowerBuilder 2017 with TFS source control

This article is a guide to connect Powerbuilder 2017 with TFS. It is important to follow the steps in the order listed in the article.

The prerequisite includes

• PB17 installed on a local machine.
• TFS server running with access to the user. A collection is required where the code will be checked in. 

Next follow the below points:

1. Team explorer 2013 : Yes the first thing needed is to install Visual studio team explorer. I know the first question pop ups in mind is if Visual studio needs to be installed on every machine !! Well the answer is NO. All you need is Team explorer 2013 to access the TFS. Second question is why 2013 ? Well there comes the 32 bit and 64 bit compatibility issues, moreover there is no standalone installer for Team explorer 2015. If you figured out a way to do it with later versions, then mention it in the comments.