{"id":6586,"date":"2020-07-28T09:00:24","date_gmt":"2020-07-27T21:00:24","guid":{"rendered":"https:\/\/www.atumvirt.com\/?p=6557"},"modified":"2020-07-28T09:00:24","modified_gmt":"2020-07-27T21:00:24","slug":"combining-citrix-adc-and-citrix-microapps-to-access-on-premises-api","status":"publish","type":"post","link":"https:\/\/avtempwp.azurewebsites.net\/2020\/07\/combining-citrix-adc-and-citrix-microapps-to-access-on-premises-api\/","title":{"rendered":"Combining Citrix ADC and Citrix Microapps to Access On-Premises API"},"content":{"rendered":"
This post is a cross-post from MyCUGC.org<\/a><\/p>\n <\/p>\n <\/p>\n Citrix Microapps service launched in 2019 and saw a realization of the value brought by the acquisition of Sapho in late 2018. Microapps help to reduce complexity involved with everyday processes in order to drive productivity gains. If you\u2019re not familiar, it is well worth checking out the overview<\/a> from Citrix. In this post we will focus on one of the latest continuous innovations added from the Microapps team to the cloud service \u2013 the general availability of the Connector Appliance for connecting to on-premesis API\u2019s. This appliance enables the cloud service to facilitate calls to services that live only within your datacenter and thereby allowing your Citrix Workspace to expose Microapps to services that were previously only available from applications within your environment. The implications for this access are far reaching as you can now potentially modernize and optimize common business tasks in order to drive productivity gains in your environment.<\/p>\n In this post we will explore deploying the connector appliance, connecting it to your Citrix Workspace, publishing a legacy API via Citrix ADC (formerly NetScaler) in order to enable HTTPS connections, then creating the integration and a Microapp.<\/p>\n In our demo case, the Windows Application GreenTree is published via Citrix Virtual Apps and Desktops for all users. A common task that was identified in a process review is address changes when employees move house. While this may be accomplished with self-service edits, the business requires this information be validated by HR in order to ensure continuity of pay. Address edits were identified as a target for Microapp.<\/p>\n Since our Demo API from GreenTree supports HTTP only, on port 9000, we will publish it using HTTPS via Citrix ADC. Load balancing is accomplished in 3 easy steps under Traffic Managerment<\/p>\n <\/a><\/p>\n Step 1, Add back end server(s)<\/p>\n <\/a><\/p>\n Next create a service group and add the service with the port. In our case, the API listens on port 9000 (non-secure HTTP)<\/p>\n <\/a><\/p>\n Click \u201cNo service group members\u201d in the next screen to add members<\/p>\n <\/a><\/p>\n Find the server in the list and enter the port number, then click OK<\/p>\n <\/a><\/p>\n In a production environment, we could also configure a MONITOR, which would allow us to do health monitoring of the back end API. For this demo, we will skip that step (and rely on the default \u201ctcp\u201d port check)<\/p>\n Create the Vserver and Bind the service group. In this case we will use NON ADDRESSABLE vserver as we will be using content switching to publish it.<\/p>\n <\/a><\/p>\n <\/a><\/p>\n In a similar fashion to before, we will work from the bottom up under the Traffic Management -> Content Switching<\/p>\n <\/a><\/p>\n Create an action<\/p>\n <\/a><\/p>\n Then a policy<\/p>\n <\/a><\/p>\n Finally, bind the policy to our Content switching vServer (or create one, similar to how the load balancing vserver was created. Give it an IP address, choose \u2018SSL\u2019 as protocol, then bind an SSL certificate as well as the policy).<\/p>\n <\/a><\/p>\n Now we can test our API publishing and we see it is working.<\/p>\n <\/a><\/p>\n Next, we need to deploy a Connector Appliance that can speak to the API. In the log into https:\/\/citrix.cloud.com<\/a>, navigate to \u201cResource Locations\u201d. While on this page, click \u201cID\u201d, copy the ID into notepad for later, then click the button for connector appliances.<\/p>\n <\/a><\/p>\n <\/a><\/p>\n <\/a><\/p>\n <\/a><\/p>\n Once the VM is downloaded to the platform of your choice, boot the device. Configure the IP address info then navigate to the URL shown in the console. You\u2019ll be presented with an 8-digit code, which you enter into this screen then register. At that point, your connector appliance is ready to chat with your on-prem API.<\/p>\n In Citrix Cloud, navigate to Microapps and create a new HTTP integration.<\/p>\n <\/a><\/p>\n <\/a><\/p>\n <\/a><\/p>\n We need the resource location ID, which can be obtained from the Resource Location\u2019s page (click the \u201cID\u201d button if you did not retrieve this earlier). Configure the authentication parameters for your API then save the integration.<\/p>\n Once the integration is saved, we need to load some data. For our demo, we will be working with HR information within our demo system.<\/p>\n <\/a><\/p>\n We will fill in the necessary data. Our API requires an API key header or query string, which we can easily add. This will vary depending on your API, so be sure to consult the API documentation. In our case, API calls must include \u201cAPIKey\u201d, so we will submit that with all requests to the endpoint \/06\/HRPerson<\/p>\n <\/a><\/p>\n If we test the service, we see the data return as expected.<\/p>\n <\/a><\/p>\n Next, we fetch the table structure from the API. We see that the result returns a JSON array with HRPersons, so we need to include a JSON pointer to ensure our table selects into the JSON result we\u2019re expecting for our table.<\/p>\n <\/a><\/p>\n Finally, we will set a primary key on the table that could not be auto generated using the pencil icon.<\/p>\n <\/a><\/p>\n Once this is saved, a sync will happen and we will head over to the tables page to preview the data. Since we see what we\u2019re expecting we can move on to synchronization.<\/p>\n <\/a><\/p>\n Let\u2019s set up our sync schedule by clicking \u201c\u2026\u201d<\/p>\n <\/a><\/p>\n <\/a><\/p>\n We\u2019re now able to move on to our Microapp. Click the \u201c\u2026\u201d then choose \u201cAdd Microapp\u201d and Navigate to the new, Blank Microapp.<\/p>\n The first stop is the Properties page for some vital info like name and icon. Don\u2019t forget to hit save at the top of the page before navigating away.<\/p>\n <\/a><\/p>\n Our workflow will call for the ability to search for users in the employee table, then edit them. We will accomplish this with an action that leads to a search page. The search results will then allow you to choose the result and edit the record.<\/p>\n We will use a FORM page tied to the Employee table. Also, we\u2019ll go back and create a second page called Employee Edit for use later.<\/p>\n <\/a><\/p>\n For our purposes, we\u2019ll add a Lookup, along with a text input that is hidden. There are multiple ways to pass data to the next details page, but in this implementation we chose using the value from the hidden text input due to issues that arose at the time of writing using the input value directly.<\/p>\n <\/a><\/p>\n Once the controls are added, click page details then \u201cEdit Logic\u201d<\/p>\n <\/a><\/p>\n The rule here sets the value of the hidden control when the value of the Lookup isn\u2019t empty.<\/p>\n <\/a><\/p>\n Configuring the search button, we add an action to \u201cGO TO PAGE\u201d, and also select conditions for the TARGET PAGE RECORD<\/p>\n <\/a><\/p>\n We set the target page record to the employee ID (\u201ccode\u201d in our table) to the one that was found using the lookup.<\/p>\n <\/a><\/p>\n Once the lookup, hidden field, and search button are configured, we can flip back over to the Employee Edit page. Using the tools on the left, we can build a nice looking grid for the various properties. Have a play with the different tools available. In our case we\u2019re only presenting the most relevant<\/i><\/b> fields, not all fields that could be edited. Remember this core principle of Microapps: You\u2019re not trying to re-invent the monolith. Keep it simple, we want the big green \u201cCOPY\u201d button on the multi-function printer here.<\/p>\n <\/a><\/p>\n When we have this all laid out, we\u2019ll back out and go edit our integration to create a service action. This service action is what we\u2019ll use to save data back to the System of Record (SoR). Go back to the Microapps Dashboard, find the integration, click \u201c\u2026\u201d then \u201cEdit\u201d, then \u201cService Actions\u201d, and finally \u201cAdd Service Action\u201d<\/p>\n <\/a><\/p>\n This request, much like the GET to populate the Microapps Service cache table, will vary by API. In our case, the API documentation states that there is a POST request to the endpoint \/{{CompanyID}}\/HRPersons\/{{code}}<\/p>\n We configure the parameters we want to send back to the database (be sure to include any mandatory parameters according to the API documentation)<\/p>\n <\/a><\/p>\n Then we can specify the mandatory bits. In this case, the endpoint is dynamic according to the URL path (for example, \/06\/HRPersons\/BROWNJ). To accomplish this, we add a PATH parameter as shown below (remember in our API \u2018code\u2019 is the Employee ID)<\/p>\n <\/a><\/p>\n Just like the \u201cGET\u201d request, this particular API still requires we send along the API key as a header or a query string. We will use header.<\/p>\n <\/a><\/p>\n Next we specify the parameters that will fill the BODY of the POST request.<\/p>\n <\/a><\/p>\n As well as the JSON structure of the body. Note the syntax of the parameter values as {{VARIABLE}}<\/p>\n <\/a><\/p>\n {<\/i><\/b><\/p>\n “HRPerson”: {<\/i><\/b><\/p>\n “UsualName”: {{UsualName}},<\/i><\/b><\/p>\n “HRNotes”: {{Notes}},<\/i><\/b><\/p>\n “IsActive”: {{IsActive}},<\/i><\/b><\/p>\n “IsSuspended”: {{IsSuspended}},<\/i><\/b><\/p>\n “StreetAddress”: {<\/i><\/b><\/p>\n “Address1”: {{Address1}},<\/i><\/b><\/p>\n “Postcode”: {{Postcode}},<\/i><\/b><\/p>\n “State”: {{Postcode}},<\/i><\/b><\/p>\n “Mobile”: {{Mobile}}<\/i><\/b><\/p>\n }<\/i><\/b><\/p>\n }<\/i><\/b><\/p>\n }<\/i><\/b><\/p>\n Lastly, for this action we want to immediately re-sync the data so that the users see the data reflected in the microapps cache rather than waiting for the next sync.<\/p>\n <\/a><\/p>\n We can now save the service action.<\/p>\n Heading back to our Employee Edit page, the various fields are mapped to the data fields from the table. The save button has an ACTION that executes a service action.<\/p>\n <\/a>Chose \u201cEdit parameters\u201d to map the parameters we\u2019ll POST back to the System of Record (SoR)<\/p>\n <\/a><\/p>\n Finally, we can now subscribe some users to our Microapp. Back on the dashboard chose \u201c\u2026\u201d for the Microapp then subscriptions. Search for a user or group to add them.<\/p>\n <\/a><\/p>\n With a user or group subscribed, we\u2019re now able to use our Microapp! In Citrix Workspace, we won\u2019t see an action until we\u2019ve used it, so click \u201cView all actions\u201d on the right.<\/p>\n <\/a><\/p>\n We can search for our user\u2026<\/p>\n <\/a><\/p>\n View their details, and optionally edit anything and it will be reflected immediately in the system of record (as well as subsequent searches in the Microapp, since we opted to re-sync after our service action).<\/p>\n