API Development

Accessing Axway Mobile Backend Service (MBS) from Axway’s Integration Builder – Part 2

| Leor Brenman |
Axway's Integration Builder

In part 1 of this series, we looked at the basics of accessing Axway’s MBS from Axway’s Integration Builder, as well as why we would want to do this.

In this post, we build on part 1 and create a real flow that performs the following:

  • Periodically queries the approvals custom object to see if there is a new approval or if there’s an approval that has been approved or rejected
  • If the approval is new, then we will send a push notification to the approver
  • If the approval has been approved or rejected, we’ll send a push notification to the requester

This project builds on the following three blog posts:

The Flow

The flow is shown below and can be downloaded here.

The flow is triggered on a schedule (as per this blog post) and performs the following:

  • Logs in as an admin user
  • Queries the approvals custom object to retrieve approvals that have been modified since the last check
  • Saves the timestamp for next run
  • Loops through approvals and does the following:
    • If approval is new, then send a push notification to the approver
    • If approval is NOT new AND is closed (approved or rejected) then send a push notification to the requester

Configure the Flow Instance

The flow has the following value variables:

The flow instance is shown below:

Flow Details

Since some of this was covered in the previous blog posts mentioned above, I’ll only cover what’s new.

Query New/Modified Approvals

We want to query the approvals custom object but only retrieve any approvals that have been modified since last check, which will also fetch new approvals. We are using the flow variable, lastCheckTimeStamp, for this and persisting it between flow executions as described in this blog post.

The two steps that accomplish this are prepareGetApprovals and getMBSCustomObjectApprovalsModified. Let’s look at these steps below.

The prepareGetApprovals step is a JS Script Step that contains the following Javascript that constructs the URL for the MBS custom object query:

let url = 'https://api.cloud.appcelerator.com/v1/objects/approvals/query.json?pretty_json=true&count=true&key='+config.mbsAppKey+'&_session_id='+steps.loginMBSUser.response.body.meta.session_id+'&where={"updated_at":{"$gt":'+config.lastCheckTimeStamp+'}}';

done({url:url});

What is key here is the where clause. We are looking for approvals where the updated_at property is greater than the last time stamp (lastCheckTimeStamp).

The getMBSCustomObjectApprovalsModified step is an HTTP step show below:

A sample response is shown below:

{
  "meta": {
    "code": 200,
    "count": 1,
    "method_name": "queryCustomObjects",
    "status": "ok"
  },
  "response": {
    "approvals": [
      {
        "amount": "1000",
        "approver": "lbrenman",
        "created_at": "2019-09-24T15:10:04+0000",
        "details": "Sales call",
        "id": "5d8a31cced77510219265751",
        "priority": "High",
        "status": "pending",
        "title": "Travel to Mexico",
        "updatedBy": "lbrenman",
        "updated_at": "2019-09-24T15:10:04+0000",
        "user_id": "578552a76e7ee8092f77bcdd"
      }
    ]
  }
}

Note that the sample response shown above is for a new approval. The MBS sets the updated_at property to be the same as the created_at property

After saving the timestamp, the array approvals above is then looped over.

Check for New

We know that all of the queried approvals have been modified since last check, so the next thing we do is check to see if the approval is new using the isNew JS Filter step to compare the created_at property as follows:

let createdAt = new Date(steps.loopOverModifiedApprovals.entry.created_at).valueOf();

done(createdAt>Number(config.lastCheckTimeStamp));

If the approval request is new, we’ll send a push notification to the approver using the prepareSendPushToApprover and sendPushToApprover steps.

The prepareSendPushToApprover JS Script step code is constructing the URL and body using the push_notification/notify.jsonMBS API and is shown below:

let url = 'https://api.cloud.appcelerator.com/v1/push_notification/notify.json?pretty_json=true&count=true&key='+config.mbsAppKey+'&_session_id='+steps.loginMBSUser.response.body.meta.session_id;

let body = {
  channel: steps.loopOverModifiedApprovals.entry.approver,
  to_ids: 'everyone',
  payload: 'You have a new pending approval request, titled "'+steps.loopOverModifiedApprovals.entry.title+'"'
};

done({url:url,body:body});

The sendPushToApprover HTTP Step is shown below and uses the url and body calculated in the prior step:

Check for Closed

If the approval request is not new, then we need to check to see if the status is closed (e.g. approved or rejected). If so, we’ll send a push notification to the requester.

The isClosed JS Filter step checks to see if the approval is closed by checking the approval’s status as follows:

let closed = steps.loopOverModifiedApprovals.entry.status == 'approved' || steps.loopOverModifiedApprovals.entry.status == 'rejected';

done(closed);

If the approval request is closed, then we need to find it’s owner (i.e. the requester) by querying MBS users by user ID. This is accomplished with the prepareGetUserById and prepareGetUserById steps.

The prepareGetUserById JS Script Step is constructing the users query API using a where clause that queries users for the desired user ID as follows:

let url = 'https://api.cloud.appcelerator.com/v1/users/query.json?pretty_json=true&count=true&key='+config.mbsAppKey+'&_session_id='+steps.loginMBSUser.response.body.meta.session_id+'&where={"id":"'+steps.loopOverModifiedApprovals.entry.user_id+'"}';

done({url:url});

The prepareGetUserById HTTP Step is shown below:

Imgur

Now we can use prepareSendPushToRequestor and sendPushToRequestor steps to send a push notification to the requester.

The prepareSendPushToRequestor JS Script Step is similar to the prepareSendPushToApprover step above and is shown below:

let url = 'https://api.cloud.appcelerator.com/v1/push_notification/notify.json?pretty_json=true&count=true&key='+config.mbsAppKey+'&_session_id='+steps.loginMBSUser.response.body.meta.session_id;

let body = {
  channel: steps.getMBSUserById.response.body.response.users[0].username,
  to_ids: 'everyone',
  payload: 'Your approval request, "'+steps.loopOverModifiedApprovals.entry.title+'", has been '+steps.loopOverModifiedApprovals.entry.status
};

done({url:url,body:body});

The sendPushToRequestor HTTP Step is shown below:

Now when an approvals is created or closed, Integration Builder can send push notifications to the requester and approver as demonstrated in the iPhone screenshot below:

You can also view the push logs in the Axway Dashboard as follows:

Summary

In this blog post, we saw how Axway’s Integration Builder can easily be used together with Axway’s MBS using the MBS REST APIs. In this example, we sent push notifications to requesters and approvers in a mobile approval application.

Discover Axway’s Integration Builder scheduled flow example.

Click Here