Alongside other technologies, Azure SDK team offers PowerShell cmdlets to manage and interact with Azure APIs. Being so powerful, Azure PowerShell has lots of cmdlets and lots of switches and parameters. Hoping to help Azure users learn more about Azure PowerShell, we introduced PowerShell equivalent cmdlets feature in Azure Resource Explorer

. 
 
 

The New tab “PowerShell” starts with providing info on how to download the latest PowerShell version. Then it lists out the equivalent cmdlets you can see in the rest of the tabs, it lists out mainly these category of cmdlets

1. GET/LIST it gets info about the current object or Lists objects in current collection
2. Actions, that include Deletion of current object, it also includes specific object actions, for example in case of a site object it shows the restart/start/stop actions
3. SET cmdlets, to show how to change the properties of an object
4. CREATE, if the current highlighted object is a list, the create new cmdlet is shown with the right parameters 
    

 Here I will go through the creation of a simple API App that takes an input and does some processing and has an output. I chose my operation to be ToUpper, it takes a string and converts all characters to upper case. To do that I used Visual studio to create and publish the API App, and then Azure portal to create and manage the Logic App. 

Let’s start by creating a new API App. To do that I had Visual studio 2013 and I had to install Azure SDK 2.5 for visual studio 2013. (I installed it using Web Platform Installer, search for visual studio azure SDK). Open visual studio, create new project -> visual C# -> Web -> ASP.NET Web Application, you will see these options:

Choose Azure API App and ok.

This will create a new project and then will add 2 main components

1. Web API: Microsoft Framework to create web services based on ASP.NET for more info please visit https://www.asp.net/web-api
2. Swashbuckle: a utility that helps create swagger api definitions for your web api for more info please visit https://github.com/domaindrivendev/Swashbuckle

The new project will have ValuesController I will just rename the controller to ToUpperController, make sure you change the controller name and the file name too to ToUpperController.cs. And this is how my controller looks like 

public class ToUpperController : ApiController
 {
 // GET api/values
 public string Get(string toConvert)
 {
 return toConvert.ToUpper();
 }
 }

In the project go to App_Start, SwaggerConfig class and enable the UI by uncommenting this 

 /*
 })
 .EnableSwaggerUi(c =>
 {
 */

Run your site and go to {localhost:port}/swagger you will see this UI:

And you can pass in any string and “try it out!” you see that the body will have the string you sent in capitalized letters. If you browse to {localhost:port}/swagger/docs/v1, you will get the swagger API definition file

Now here is the trick that took me some time to figure out, Logic apps only work with the default response and not the 200 response defined in the swagger JSON  

So to add default response to all your APIs here is what you need to do is to go to SwaggerConfig.cs and do the following

1. Uncomment
   

   c.OperationFilter<AddDefaultResponse>();

    
2. Add the following class

   public class AddDefaultResponse: IOperationFilter
    {
    public void Apply(Operation operation, SchemaRegistry schemaRegistry, ApiDescription apiDescription)
    {
    if (!operation.responses.ContainsKey("default") && operation.responses.ContainsKey("200"))
    {
    operation.responses.Add("default", operation.responses["200"]);
    }
    }
    } 

And that is how the swagger response will look like:

Now we are ready to publish to a live API App, right click on the project then hit publish. To do that you need to be signed in to Azure and you need a subscription. Documentation on how to publish API App here 

Ok now let’s play with the new API App that we created, go to the portal and create a new twitter API app, just search Azure marketplace and install the package “Twitter Connector”.

Once you have all deployed, create a new Logic app, go the designer by clicking triggers and actions.

In my scenario I will trigger this flow manually so I will check the box “Run this Logic Manually”, now it will ask to drop in an action, from the right list drop in twitterconnector, I will choose search tweets action, and I will search for Azure. Now drop in your API App in and choose the only action you got now “ConverToUpper_Get” it will ask for input called “toConvert” let’s click on the “…” button to get a list or parameters that we can get from the previous action. I will choose Search Tweets Tweeted By as input. Notice here it only shows the “variables” that are of type string, because we specified that our input to the API is string. This is how the design will look after you are done

 

Now save your changes, close the designer and go back to the Logic App blade and click “Run Now” you will see in the operation part a new run shows up, if you click on that you can get to the results of the run 

 

Now if you open the logs for each action you will see 2 links “INPUTS LINK” and “OUTPUTS LINK” each will open JSON data files that contain the information. If you go to your ToUpperApp input links you will see something similar to this:

And to outputs link you will see that the name DanWahlin was transformed to Capital letters and is sent back in the body.

Now you have created the API App from scratch and it can take in parameters and send back ouputs. That opens up the gate for lots of innovative Logic apps you can easily and rapidly develop.

 

In Azure web sites, there are many ways you can change PHP default configurations. You can enable custom extensions, you can use a .user.ini to change the non system-level-only directives or you can even bring in your own runtime bits of PHP. For more details read this article.

This post is to add another way to customize your PHP.ini configuration. To understand how it works there are 2 concepts we need to go through

1. Azure Websites is a shared hosting environment, where multiple sites can exist in the same host machine.  When a site comes up, a dedicated PHP.ini file gets created. This file is used only by that site. If you want to go through that file to see the default values you can do so through your scm site. Go to <your site name>.scm.azurewebsites.net, sign in with your Microsoft account, then you get to Kudu interface (Kudu is an awesome tool that comes with Azure Websites, if you do not know about it, here is a brief intro in this post). Using Kudu you can navigate to the location where your PHP.ini exists.
1. Go to Debug Console -> cmd
2. Click on the globe icon, then navigate to config folder, PHP version you are using
3. Click the edit button and you get an editor that has all the content of the php.ini used for your site.
   
    Note: these config files files are read only.
2. In PHP you can specify a location, and PHP runtime will look at all .ini files in that directory and append it to the configurations in the main PHP.ini. I really could not find any documentation whatsoever to that feature, but it exists :)

Combining this knowledge with the knowledge on how to add appSettings to the Azure Websites, we can make advantage of that PHP hidden treasure and here is how.

In the portal or the preview portal, you can do all of these steps but for the purpose of that post I will use only the preview portal.

1. Go to your website -> All settings, you will find a section called App settings.
   
    

2. Add this app setting PHP_INI_SCAN_DIR with a value that is a directory in your site, in this case I decided to put it in D:\home\site which is a directory that is not in the serve-able wwwroot folder, but you still can publish to it either using FTP or by using the awesome magic of Kudu. Do not forget to save the changes.

3. publish a simple site with an index.php that has this content 

   <?php
    
    phpinfo();
    
    ?>  

   This will print out PHPInfo page
   
   

   You can see that now it shows the “scan this dir for additional .ini files” is pointing to D:\home\site. 

Now you can put any .ini files in that location and they will be simply appended to the PHP ini configurations. Let’s play with that a little
I will first try to drop an empty .ini file make sure it was loaded by PHP runtime. I do this by opening Kudu and then drag and drop the file in the folder I want to publish to, cool huh!

 Now restart the site and refresh the index.php and here you go, the empty ini shows up.

 
Now let’s add another ini file that really does something, I will add a file  NewConfig.ini and the content will be

mysql.max_links=5

and again use Kudu magic to just drop it in D:\home\site. Here is the output of phpinfo before and after

Before:

After adding the file and restarting the site:

Then I added this to my new ini file

upload_tmp_dir=D:\home\site\uploads

restarted the site, then I see the change reflected in phpinfo page.

Using this method you can even enable new extensions by adding an ini file that has the content

zend_extension=D:\home\site\php-ext\php_xdebug-2.3.1-5.4-vc9-nts.dll

or

extension=D:\home\site\php-ext\php_gd2.dll

Make sure you upload the extensions in the right directory and that would effectively enable your custom extensions.

In conclusion, hosting a PHP site on Azure Websites platform is easy and reliable. In addition, you can get higher level of control on your PHP site by setting the PHP configurations you like.

Related resources that I found useful:
https://microsoftazurewebsitescheatsheet.info/