Consuming Protected Rest Service in Process Cloud Service Form Rules.

Recently, I was working on a customer requirement where in I had to invoke protected REST service that returns JSON and pre-populates the Web Form. 

The below shows the steps on achieving the same.

1.     In Process Cloud (BPM) Workspace, Select Administration and Credentials

2.     In Credentials, create a new Credential for Forms Rules. The credentials should be of type "Web Form Rest Services Credential". Give the necessary details like base url, user name & password & Click Save & Log out of the work space

3.     Login to the composer and go to your web form.

4. Click on new/existing form rules & use the below code

if(buttonClickedr.clicked) //On Click on Button

{

try {

      var uri = "https://www.protectedrestservice.com:80/PCS/previousOrder?supplierId=6666&storeId=2";

var data = http.get(uri);

      }  catch (e) {

        Desc.value = 'got exception' + e ;

   }

Desc.value = data;

} 

Make sure the url matches the key that you had created in the workspace.

Test the form rule. You should be able to see the response from the REST invocation into the description field.

12 Factor Apps - What is it?

It’s a  methodology for developers to follow when building modern web-based applications. These rules are typically applied to SaaS/Cloud based/Multi-tenant application

12 Factor Apps

Code Base: One Code base for all our applications. It could be Git, SVN, etc.\

• Can there be multiple code bases? No. If it has, this  means it’s a distributed system. So each system in distributed system should be considered as an application and then each app should follow 12 factor app rules
• Can multiple app share the same code? Yes. But only as a library which is then managed by dependency manager

Dependencies: 12FA should be explicit about dependencies. For example having manifest that gives details of dependencies. For example if you application uses a database connection within java, never assume that server you would be deploying will have the required libraries. So you give all the required details like lib, version, etc and when you build it, the app downloads all the respective libraries

Configuration:  Different deployment may have different configuration. As a best practice, it is often said that config and code must be separate .i.e. apps that store configurations in code as constants is not acceptable.

The twelve-factor app stores these configurations in environment variables  These vars are easy to change between deploys without changing any code and unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.

Backing Services:  It’s a service that your application may use. It could be external db connection or email connection. The code adhering to twelve-factor makes no distinction between local and third party services. To the app, both are attached resources, accessed via an URL with credentials being stored in the configuration file. For example, if the app’s database is misbehaving due to a hardware issue, the app’s administrator might spin up a new database server restored from a recent backup. The current production database could be detached, and the new database attached – all without any code changes.

Build/Release/Run: The 12FA follows strict separation of Build, Release & Run.

a.       Build Stage: Application Code is compiled. This could also fetch vendor dependencies.

b.      Release Stage: Build Stage + Configuration (specific to deploy environment)

c.       Run Stage: Actual execution of the app.

By strict separation I mean For example, it is impossible to make changes to the code at run time, since there is no way to propagate those changes back to the build stage.

Processes: 12FA processes should be stateless and share nothing. If any data needs to be shared between restarts or releases, it should be stored in the database.

Port Binding: 12FA should be totally self contained. This means any application that relies on web server is not 12FA. Instead these apps bind to port and listens to request directly.

Concurrency:  Scale out via the process model

Disposability: The twelve-factor app’s processes are disposable, meaning they can be started or stopped at a moment’s notice. This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys.  This mean applications should have little startup time as possible and apps should be robus against sudden death.

Dev/Pro Parity: Keep Dev/QA/Production environment as close as possible. Usually there are substantial  gaps due to time any other release. The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small. So in 12FA, code is moved between deployment sooner that earlier, developers are more involved with deployment process and tools used in various environments are similar.

Logs: Logs provide visibility into the behavior of a running app. In server-based environments they are commonly written to a file on disk.  A 12FA is never worried about storage of its output stream. It should not attempt to write to or manage log files. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior. In production, these logs can be captured by the execution environment, collaged and routed to final destination like Splunk

Admin Processes: Run admin/management tasks as one-off processes .i.e. having scripts compared to running individual commands.

For more information, refer to the below link

http://12factor.net/