Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Get Started With MultiChain on Windows PC (Part 2)

DZone's Guide to

Get Started With MultiChain on Windows PC (Part 2)

In this post, we will discuss how you can create a Java client to interact with your chain. Read on to get started securing your app!

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

In the first part of this how-to tutorial, you saw how you can create a private chain on the Multichain platform and interact with it through the command line.

Part 1 can be found here.

In this second part, we will discuss how you can create a Java client to interact with your chain.

You can find the GitHub link to the project at the end of this article so you can download it and see it in action.

Our Goal

In order to interact with your chain and get responses, you have to ‘talk’ to the chain using RPC calls. If you remember from part 1 of our how-to guide the final format of your RPC call is the following:

{"method":<method_name>,"params":<params_as_array>,"id":<unique_id>,"chain_name":<chain_name>}

So in order to interact with the chain, you have to construct the RPC call with the following information:

  • Method_name
  • Parameters_if_any_else_pass_null_value
  • Unique_id_number
  • Chain_name 

Parameter chain_name is not actually needed, but if it is there it is used as a check.

Method_name is the name of the API command you want to call. So if you want to get information about your chain you can call the ‘getinfo’ command and get all the information. Or if you want to create a new stream in your chain you call the ‘create’ command.

Parameters are not always necessary. There are some API commands that takes no parameters. Examples of those commands are ‘getinfo’, ‘help’ or ‘stop’. There are also commands that take one or more parameters. Examples of those commands are ‘liststreams’, ‘listaddresses’ and many more.

Unique_id_number is the number you have to pass to the RPC call. It is the unique id of the call and you can generate it easily using java’s UUID class.

Chain_name is the name of your chain. You gave it to the chain when you first generated it. In our example, it is ‘tutchain’.

RPC Client

The first step is to create the client, set credentials, and HTTP connection parameters and use it! Our client needs to know the IP, Port, Username, and Password in order to ‘talk’ to the chain.

In our example, we are using Apache httpclient 4.5.5. You can see in our configuration file with name HttpClientConfig the methods we use for setting the parameters to the HTTP client.

We get a Bean of CredentialsProvider by using:

public CredentialsProvider getBasicCredentialProvider() {
  return new BasicCredentialsProvider();
}

And then we are configuring it with our parameters:

public CredentialsProvider configure(CredentialsProvider credentialsProvider) {
  credentialsProvider.setCredentials(
    new AuthScope(
      chain.getIp(), 
      chain.getPort()),
    new UsernamePasswordCredentials(
      chain.getUsername(), 
      chain.getPassword())
  );
  return credentialsProvider;
}

After we configure the credential provider we set it on our HTTP client:

public CloseableHttpClient getHttpClient() {
  return HttpClientBuilder
    .create()
    .setConnectionManagerShared(true)
    .setDefaultCredentialsProvider( configure(getBasicCredentialProvider()) )
    .build();
}

And we now have a closable HTTP client fully configured.

So far we are good but where did those chain.getIP, chain.getPort, etc., come from.

Chain Class

As we discussed earlier our client needs to know the IP, Port, Username, and Password in order to interact with the chain. But what about the scenario where we want to have two or more chains and perhaps compare them at some point?

This is the reason we are passing this information as an object. Our Chain class holds this information. So when we are configuring our application we are setting this information to the Chain object.

We are ejecting the Chain object into the Configuration class and we have all the information about the IP, Port, etc., available.

Calls and Responses

Having done all the above necessary steps, our client is in position to make RPC calls and get responses. The responses that we get are depending on the API command we used for the call in the first place.

The responses we are expecting to get are of the following categories:

  • String response. This response is either the result of a command that informs us about something (example ‘help’ command) or the result of a command which returned a HASH code (example the creation of a record in the chain).
  • Object response. This is the result of command which returned information in a JSON object. Example of this response is the ‘getinfo’ command which returns information about our chain. Some of the properties in this JSON response are; version, nodeversion, port.
  • List of Objects response. It is basically the same as above but this time it is a list of objects. Example of this response is the ‘liststreams’ command.

Response Object

We talked about the responses and how different they might be. Responses are JSON objects with several properties. So it is not so simple to make it a POJO class.

Take into consideration that only the ‘getinfo’ command generates 27 properties. The ‘getruntimeparams’ has 21 properties. So what you can do to have it as a POJO class?

You could create POJO classes for your responses and each class could have as properties the JSON properties you are expecting as the response. Doing so you would eventually have a GetInfo class with 27 properties and so on.

You could create a generic object. This is more complex but it sure is a good solution.

Another way – our way in this how-to – is to have a unique POJO class with all the properties. And they are a lot! We will create our custom annotations and tag the appropriate properties in our POJO with the necessary annotations so we will know which properties correspond on which API command. So we will have a @Getinfo annotation above every property that we expect to have value after ‘getinfo’ call. So 27 properties will have the @Getinfo annotation.

Time for Code

Let’s see how we can do a call and get the response from our chain.

You can find four examples demonstrating all the scenarios in the GitHub link.

Step 1 – Initialize Chain

First of all, initialize your chain object by passing the necessary parameters. Your password can be found inside multichain.conf file.

Chain tutchain = Chain.initialize("127.0.0.1", 6752, "multichainrpc", AeU1Z3XtfNwu4BGJiDDciTGn1NgPaogFZ879JBRsVqgD", "tutchain");

Step 2 – Set Chain Object on Example Class

The Example class is the class with the four available examples you can use in order to get different available responses. Prepare the example object by setting the chain object that you will use.

Example example = Example.forChain(tutchain);

Step 3 – Get Object Response From the Chain

This is example No.2 in which you can see how you can do the call and get the response. In this example, the expected response is an object containing values for all the properties that carry value from the response. The rest of the properties are all null.  

ObjResp response_info = example.getObjectResponseNoParams();
response_info.toString(GetInfo.class);

Here method getObjectResponseNoParams() of the Example class calls for the following code:

jsonInString = chainService.apiCall(params, Method.GET_INFO, chain.getChainName());

As you can see we are using method ‘getinfo’ so we expect the response as an object.

Finally, we call method toString(GetInfo.class) in order to filter out all the null values and type only the properties that carry values from the response.

GitHub link to project:

https://github.com/kgiannis/multichain_client_java

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
blockchain ,blockchain app development ,multichain ,java ,security

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}