Skip navigation
1 2 3 Previous Next

Digital Workplace

44 posts
Share This:

Today, we are excited to announce BMC Digital Workplace 19.08. The latest release of Digital Workplace includes exciting new end user and administrator enhancements to help bring organizations into the Future of Work !


All of the following enhancements are available for BMC Digital Workplace Advanced. Enhancements marked with an asterisk (*) are also available for BMC Digital Workplace Basic

End User Experience


Active Events*



Filter and search against active Events.


Page Size*


Control the volume of records being displayed





Managed Services


Add and manage additional customers.



Credit Management


Optionally replace currency with a credit based system.



Once a Service Request is submitted the assigned credit is deducted from the balance above.


Default Language*


Control the default language of your organization



Order ID*


Order ID is no longer associated with an individual request and has been replaced with Request ID. Order ID's are now applicable to multiple items only.


Password Question


Create a password question and enforce a regular expression. Optionally choose whether to encrypt the password.



Counter Question


Add a counter question and choose your increment.


Conditions across questionnaire pages


Conditions are now supported across subsequent pages.


Default Requested Login Name


Set the default answer to requested "For" or "By" Login name.






For version details of Remedy ITSM Remedy AR System  HR Case ManagementClient Management Atrium CMDB Cloud Lifecycle Mgmt please refer to our Compatibility Matrix.



Next Steps


For a comprehensive summary of all enhancements please refer to our Digital Workplace Advanced and Basic documentation                                                                  

Share This:

BMC Software announces the 19.05 release of BMC Digital Workplace. This release delivers significant new functionalities requested by customers.


All of the following enhancements are available for BMC Digital Workplace Advanced. Enhancements marked with an asterisk (*) are also available for BMC Digital Workplace Basic

End User Experience



Satisfaction Surveys*


Single question surveys are now also available for Catalog Requests.



To view the rating simply open the Report in the Catalog Administration Console.


Enhanced Email Templates*


Cross launch into Digital Workplace using HTML Templates.




Notification settings*


Change notification preferences.



Progress Bar


Quickly view the progress of a Service Request.



Auto Dependent Services


Add dependent Services automatically.





An additional grey navigation style is now available.



Change the name of the Browse Category button or modify the default search placeholder and result filters.


Catalog Dashboard


Browse dashboard categories and view Connector health.





Click for guided assistance and links to help topics & videos.



Bypass permissions


End users can now transparently access forms with special permissions.







For version details of Remedy ITSM Remedy AR System  HR Case ManagementClient Management Atrium CMDB Cloud Lifecycle Mgmt please refer to our Compatibility Matrix.



Next Steps


For a comprehensive summary of all enhancements please refer to our Digital Workplace Advanced and Basic documentation                                                                              

Share This:

Integrating the Digital Workplace Catalog with BMC Asset Management allows users to view their Assets from the "MyStuff" Tab. We can also add Asset Actions to launch Service Requests and dynamically populate them with Asset information.


A common example would be reporting a problem against an existing asset or requesting a new one.



To enable this integration in the Catalog, click the gear icon on the top right hand corner of the Administration page.



Only Assets which belong to the logged in user (owned or used by) can be displayed in MyStuff. To add or modify ownership open the Asset Console and update the People tab with the owner/user.




Before we can view these assets in Digital Workplace we also need to add the associated classes into a new or existing group within the "Asset Groups" section in the Catalog.


Now that we have grouped our assets we can associate an action to retrieve asset information and optionally launch a Request with this information in BMC Digital Workplace. To achieve this functionality create a Service Action and add a questionnaire with whatever fields you may be interested in from Asset Management.



Next, open the question designer and create questions for each of the fields you'd like retrieve data from. In the example below we have a drop down menu which is linked to three possible sets of Asset questions.



Now let's create an action to automatically fill in each of these questions from Asset management as soon as the questionnaire is opened. To do this we use the "Open questionnaire" Trigger" with the "AST:BaseElement" form with a qualification of 'Reconciliation Identity' is 'Asset External ID'. This means only information against the Asset I choose will be returned.



By selecting fields from the "AST:BaseElement" form we can map asset data against each of our text questions.


Finally, we're ready to associate this action with each of our Asset Classes.




In order to view and launch actions we simply navigate to the "MyStuff" page and choose whatever action has been defined.


As soon as we select "Report Asset problem" the Request opens and automatically populates with the relevant data from BMC Asset Management !


In summary, not only are we giving users more visibility about their Assets we're also reducing the level of effort to retrieve and accurately report against dynamic Asset Data !

Share This:

The new branding interface replaces the previous process, and eliminates the procedure that required you to update and copy the CSS to apply your branding changes. Use a convenient interface to customize the logo, name, and colors as per your requirements. The new responsive user interface allows your changes to be seamlessly made available across various desktop and mobile devices. Since the previous tenant.css is no longer applicable, you will need to apply your branding using the new branding interface.


In addition to the above branding options, you can use the BMC Digital Workplace Admin Console to easily hide the following features from your end users:

  • Shopping Cart
  • Catalog Ratings and Reviews
  • Knowledge Article Feedback
  • Similar Knowledge Articles
  • Social Activities
  • Posts

For more information, see Rebranding BMC Digital Workplace - Documentation for BMC Digital Workplace Advanced 19.02. For a complete list of new and updated features that have been released, see 19.02.00 enhancements - Documentation for BMC Digital Workplace Advanced.

Share This:

BMC Digital Workplace provides a new responsive user interface in the 19.02 release. The new UI is designed based on the Progressive Web App that supports desktop and mobile devices.

  • All features and branding changes are seamlessly made available on desktop and mobile devices.
  • An iOS native app that supports push notifications and QR code scanning is available.

Client deployment flowchart

Use the following chart to see the available client deployment routes.

Clients deployment options in 19.02.png

Mobile device options

All features such as push notifications, and QR code scan will continue to work with this release on the supported mobile clients. Please see below for a consolidated list of available options on your mobile devices:

Mobile deployments.png

For a complete list of new and updated features that have been released, see 19.02.00 enhancements - Documentation for BMC Digital Workplace Advanced.

Share This:

BMC Digital Workplace 19.02 is Now Available. This release delivers significant new functionalities that customers have requested, including enhancements to the end user experience and catalog capabilities.


All of the following enhancements are available for BMC Digital Workplace Advanced. Enhancements marked with an asterisk (*) are also available for BMC Digital Workplace Basic.

Revamped User Interface



Progressive Web Application (PWA)*


Dynamic "app-like" experience on your Device browser or Desktop.



Active and Past Events*


Quickly view current and past events via the My Activity page.



Bundle details


View in-depth bundle details.



Multiple approval view*


View all pending approvals simultaneously.



Search functionality*


Select previous search results and refine by filtering.



Optional Social functionality*


Open application preferences to view social activity.




Service health tab


Services now have their own dedicated tab.




Digital Workplace Admin enhancements


Rebrand the PWA User Interface*


Quickly rebrand the PWA User Interface and changes will be automatically reflected across desktop and mobile clients.



PWA on iOS doesn't currently have the ability to receive push notifications. Please download the "Digital Workplace" app from the App Store

to enable this functionality. The rebranding changes will be visible on login.

Mobile view



Desktop view



Build a custom home page


Build your own custom page and modify layouts.



Hide functionality*


Hide additional functionality via the DWP Client Administration console.



Collaborator preferences


Create and load a default collaboration Group.


Change Log Level*


Quickly change the log level in both the DWP Client* and Catalog



Questionnaire Tags


Add internal tags for use in workflow.




Copy Catalog questionnaire


Optionally copy questionnaires with workflow.



Date restrictions for questionnaires


Choose active duration.





For version details of Remedy ITSM Remedy AR System  HR Case ManagementClient ManagementAtrium CMDB Cloud Lifecycle Mgmt please refer to our Compatibility Matrix.

Next Steps


For a comprehensive summary of all enhancements please refer to our Digtal Workplace Advanced and Basic documentation

Share This:

This article follows up on a previous article where we looked at setting up the API to integrate DWP Catalog with remote servers. We looked at the connector description and the various calls that need to be defined. If you followed along you hopefully ended up with a working interface.


But that’s all it is for now: an interface. A lot of the values we’re returning are hardcoded and it doesn’t do anything at the moment. What I want to do next is explain how to build a full integration. We’ll use the same interface, so if you haven’t already done so, make sure to read my first blog article.


What are we going to build? It can’t be too complicated, so what I propose building is a simple ping activity. The basic idea is that you can invoke the action to check if a server is online. It will send out a ping request and report back if the server can be reached or not. You could use this in your workflow to check if a server can be reached, and depending on the outcome you can engage a specific team or escalate it further. We’re going to output a Boolean so that will work nicely with Exclusive Gateways.


Just to remind ourselves, this is how the integration works:



What we are interested in is the connector logic. Our action will return a Boolean indicating if the machine is alive or not. Using the same overview, these are the relevant components:



Notice I’m not going to an external server, I’m just executing code to do the ping which is all Java. Let’s first write a simple Java class, just so we know what the code looks like and how it works. This is what I came up with:


package pingservicetest;


public class PingServiceTest {

  public static boolean isMachineAlive (String machineName, int machinePort) {
    try {
      InetAddress inet;
      inet = InetAddress.getByName(machineName);
      return inet.isReachable(500);
    } catch ( e) {
    } catch (IOException e) {
    if (machinePort == 0) {
      machinePort = 111;
    try (Socket s = new Socket(machineName, machinePort)) {
      return true;
    } catch (IOException ex) {
    return false;

  public static void main(String[] args) {


I want to check if servers are available or not, so I need to execute some form of ping command to confirm that they're alive. There's no TCP ping command in Java, but I can just use InetAddress. If I don’t get a response I try an additional Socket call. If I can get a successful connection I return true, if not I return false. I included the example at the end of this article, which you can run if you want to. It’s nothing fancy but it’s a good example of the way you can extend Catalog’s functionality.


I don’t like to put everything in one big file, so to make it manageable (and mirror the original diagram) I’m splitting this in two classes:


  • RCFController handles the interface. Its primary role is to accept HTTP requests from Catalog and respond with the correct JSON code.
  • RCFLogic is new, this is the class containing the code which does the actual processing. In our case that’s the isMachineAlive method.



Let’s start with RCFLogic. We already wrote and tested our code so we just need to define the class:


package rcf;


public class RCFLogic {

  public static boolean isMachineAlive(String machineName, int machinePort) {


Nothing new there, it’s a typical Java class, no references to Spring or Catalog. All of this is separate, but needs to be referenced properly. We need to know what the service accepts, what goes out and what format this is in. The interface we used in the first article can stay largely unchanged but I need to add the Port as an input and return a Boolean instead of a String. Here’s the action part of descriptor:


"name": "isMachineAlive",
"displayName": "isMachineAlive",
"path": "isMachineAlive",
"inputs": [
    "name": "machineName",
    "type": "String",
    "required": true
    "name": "tcpPort",
    "type": "Integer",
    "required": false
"outputs": [
    "name": "Result",
     "type": "Boolean"


I accept machineName and tcpPort and I return a Boolean called Result. I use the same code based on org.json as last time. Based on this I know I get this HTTP request in from Catalog:


POST http://server:8080/jbconnectivity/pingMachine HTTP/1.1

  "inputs": {
    "machinePort": null,
    "machineName": "clm-test-12345"
  "connectionInstanceId": "jbconnectivity-1"


The request is generated by Catalog, but it bases this on the definition which I supplied and uses the values set during workflow creation. I write my code in the controller to handle this. I also know what the HTTP response should be:


HTTP/1.1 200



With some help from org.json and Spring this is the code I came up with:


@RequestMapping(value = "/jbconnectivity/pingMachine", method = RequestMethod.POST)
public String checkPing(@RequestBody String payload) {
  JSONObject jsonPayload = new JSONObject(payload);
  String machineName = jsonPayload.getJSONObject("inputs").getString("machineName");
  int machinePort = 0;

  try {
    machinePort = jsonPayload.getJSONObject("inputs").getInt("machinePort");
  } catch (JSONException e) {}

  JSONObject jsonInputs = new JSONObject();
  jsonInputs.put("result", RCFLogic.isMachineAlive(machineName, machinePort));
  JSONObject jsonPing = new JSONObject();
  jsonPing.put("outputs", jsonInputs);

  return jsonPing.toString();


I first accept the payload from the POST request which I convert into a JSON object (jsonPayload). I then extract the machine name and the port (the try/catch clause is just to deal with the null value). Once I have all the values I create the JSON I want to respond with (jsonPing and jsonInputs). The point where I call my method in RCFLogic is line 13.


That’s all I’m going to do. Because I don’t connect to an external system, I don’t have to do any health checks, so I’m just going to keep the hardcoded values for checkHealth. Sure, there are things that could be improved, I’ve done some housekeeping in the actual example which I’ve attached at the end of the article, but I hope you get the principle.

Okay, let’s give it a go! I’m keeping the workflow as simple as possible, no fancy conditions, just two questions and one activity.



Curious if it’s going to work? Let’s log into DWP and create a new service request:



Because my workflow doesn’t actually create any requests in a backend system, I’m just going to have a look at the Service Requests report on the Catalog side:

And lo and behold, it works! Catalog executed the action, sent a POST request to the API as per the definition. My code picked up the POST request and called the isMachineAlive method in the RCFLogic class. And that was all passed back to DWP.


I know, this is fairly basic but I hope you agree that it works quite well. We’re separating Catalog from the external integration by using an API which adheres to strict standards. As long as I make sure I define the interface correctly, it’s up to me to respond to the incoming HTTP requests. It doesn’t really matter what you do in the backend to process the request. It can be as simple as extending the functionality by adding a few custom actions to calculate a week number based on a date, or it can be as complicated as integrating using SOAP-based web services. But keep in mind that this doesn't allow you to interact with DWP, you can't write a service which pushes values to DWP directly, it's all in the background. But it’s up to you and I look forward to seeing what you will come up with. Any questions or feedback? Leave a comment below.


Best wishes,


Share This:

It won’t come as a surprise to you that Catalog integrates seamlessly with ITSM. It’s easy to create work order and incident records. As a backend fulfilment system, integration is key and Catalog interacts with various systems using out-of-the-box connectors like Active Directory, Flexera or MS Office. For most other needs Catalog uses Integration Service which makes it possible to interact with a whole range of other connectors and even allows you to write your own.


This should take care of the majority of your integration needs, so is there a need for the ability to integrate directly with remote servers? It’s a recent feature, added only in 18.11, which makes it possible for Catalog to connect to external servers using a HTTP-based interface. Is there any benefit to this? I’d argue there is: while there’s greater work involved in building your own interface, there is also greater flexibility.


I really like the solution for connecting different cloud-based applications, but it has its drawbacks: Integration Service is a cloud-based solution, so even if you want to connect your on-premise Catalog server to your local application, it requires you to do this via the cloud. Integration Service also requires a license, and the solution might not be right for you if you’re looking for a small integration or extension.


Direct integration with remote servers resolves this. It puts you in control of the integration, both in terms of design and development, but also the hosting location, without any need for an intermediate connection to the cloud. It also suits small-scale extensions, if you want to add some specific functionality or want to integrate with a local application, this might be the solution for you.


True, in most cases the combination of out-of-the-box connectors plus Integration Service is enough. But for a backend fulfilment system, integration is paramount and we’ll make every effort to ensure you’re successful.


Does this mean that it’s going to be easy to set up? I can’t promise you that. The truth is that you have to build everything yourself, there’s no framework and there are no connectors. You build the server, design the API and all of this has to adhere to a strict standard. Daunting? I agree, but still doable. And I’m here to help.


Let’s first talk about the various components. I’m going to deviate slightly from the official documentation as I find it easier to explain it this way. Here’s how I see the integration:

DWP uses Catalog as its backend fulfilment system: users submit requests and Catalog handles the workflow process as part of the service. Catalog has the ability to integrate using out-of-the-box components, Integration Service and Remote Connectors. The Remote Connector is a web-based application which runs on a web server. The key part of this is the HTTP-based API, that’s the part Catalog interacts with. The interface adheres to a specific standard: there are certain requests that will be made and Catalog expects responses in a certain format. The API in turn uses the connector logic to do whatever is required to process: calculate something, return data, create requests, etc. It’s up to you how you want to do this. Notice I used a dashed line for the external system. The primary reason would to communicate with the external system, but this doesn’t necessarily have to be the case. If you want to return week numbers based on a date, that’s absolutely possible.


As far as Catalog is concerned it’s communicating with the API, it doesn’t really matter to Catalog what’s happening further upstream, so what we need to do first is define this interface. I’m going to show you how to build a full connector, but I will spread this over two articles, in this first article I’m only going to build the API part. I’m not actually building the connector logic or integrate with an external system, this will just overcomplicating things and stand in the way of explaining the connector properly. We’ll leave this to the second article. This what we’re going to build:

We have to do everything from scratch, in order to get this API working we need to write a web based application which accepts certain HTTP requests and responds in a certain way. These are the calls we need to get the service registered:


GET /rcf/description


This request will be sent when you set up a remote connector in the Catalog configuration, it’s the first request that goes out. If you’re familiar with SOAP web services, then this is the equivalent of a WSDL: it describes the service, lists what is on offer, what it expects and what it will send back in return. Catalog will use this information to build the service. As with the WSDL, the format is specific and you need to make sure you follow the format exactly.


GET /rcf/health


This is the second call that goes out when registering the server, it validates the server. It should respond with a simple OK.


Those are all the calls we need to get everything registered. So before we go any further let’s get these calls defined. I’m using the Spring framework for the web server. It’s easy enough to spin up and it offers the flexibility I am looking for. I am using Maven as my build tool-of-choice, but just to clarify, there are no requirements here, if you want to use something else, you can. My interface communicates via JSON and to keep it simple and readable I decided to use the org.json library, there are of course different options.


If you decide to follow me, download/install Maven from here and set up an empty project with the appropriate Spring references (see below for references). Then run these commands to build and start everything:


mvn clean package
java -jar target/gs-rest-service-0.1.0.jar 


This starts a web server which I can access via http://myserver:8080/


Here are the files I am using:

  • src\main\java\rcf\ main controller, contains request definitions
  • src\main\java\rcf\ Boot application, used by Spring to start application


In Spring HTTP requests are handled by a controller identified by the @RestController annotation. My controller handles the various requests for the RCF web application. Let’s start with the simplest call, /rcf/health:


@RequestMapping(value = "/rcf/health", method = RequestMethod.GET)
public String getHealth() {
  return "OK";


I specified that I accept a GET request, I define the URL and I set the response. In our case a simple ‘OK’. That’s enough for this to work.

Let’s turn our attention to /rcf/description. This is an important call, here’s the overview of what we need:


  "connectors": [
      "name": "Machine Connectivity",
      "version": "0.1",
      "type": "com.example.jb.connectivity",
      "path": "jbconnectivity",
      "capabilities": [],
      "activeConnectionInstances": [],
      "actions": [
        "name": "pingMachine",
        "displayName": "pingMachine",
          "path": "pingMachine",
          "inputs": [
              "name": "machineName",
              "type": "String",
              "required": true
          "outputs": [
              "name": "Result",
              "type": "String"


We start with an element called connectors which is an array of the different connectors. Each connector translates to a category in the workflow palette.


There are a few properties you need to set, notice the path which you’ll need to use later during run-time. Capabilities is a list of tags describing what the API offers, we’ll look into this later. ActiveConnectionInstances is a list of the available instances like Dev and Prod, this is used in case you use different environments. Next, we've got the actions, this is an array so each connector can have more than one action. This part is fairly self-explanatory: there's the name and you've got the inputs and the outputs. Here's what this looks like on the workflow panel:



Like the health check we need to define the request as part of the controller. Since we’re dealing with json code I am using org.json. Here’s the code:


@RequestMapping(value="/rcf/descriptor", method = RequestMethod.GET)
  public String descriptor() {

  JSONObject jsonDescription = new JSONObject();
  JSONArray jsonArrConnectors = new JSONArray();

  JSONObject jsonConnectionInstance = new JSONObject();
    jsonConnectionInstance.put("id", "jbconnectivity-1");
    jsonConnectionInstance.put("name", "Production");
  JSONArray jsonArrConnectionInstance = new JSONArray();

  JSONArray jsonArrCapabilities = new JSONArray();

  JSONObject jsonAction = new JSONObject();
    jsonAction.put("name", "pingMachine3");
    jsonAction.put("displayName", "pingMachine3");
    jsonAction.put("path", "pingMachine3");
  JSONArray jsonArrAction = new JSONArray();

  JSONObject jsonActionInput = new JSONObject();
    jsonActionInput.put("name", "machineName");
    jsonActionInput.put("type", "String");
    jsonActionInput.put("required", true);
  JSONArray jsonArrActionInput = new JSONArray();
  JSONObject jsonActionOutput = new JSONObject();
    jsonActionOutput.put("name", "Result");
    jsonActionOutput.put("type", "String");
  JSONArray jsonArrActionOutput = new JSONArray();

  jsonAction.put("inputs", jsonArrActionInput);
  jsonAction.put("outputs", jsonArrActionOutput);

  jsonAction.put("com.bmc.dsm.catalog", JSONObject.NULL);

  JSONObject jsonIndividualConnector = new JSONObject();
    jsonIndividualConnector.put("name", "Machine Connectivity 3");
    jsonIndividualConnector.put("version", "0.1");
    jsonIndividualConnector.put("type", "com.example.jb.connectivity");
    jsonIndividualConnector.put("path", "jbconnectivity");
    jsonIndividualConnector.put("capabilities", jsonArrCapabilities);
    jsonIndividualConnector.put("activeConnectionInstances", jsonArrConnectionInstance);
    jsonIndividualConnector.put("actions", jsonArrAction);
  jsonDescription.put("connectors", jsonArrConnectors);

  return jsonDescription.toString();


I’m hardcoding a lot of the values, that’s a deliberate choice to make it readable. In the next blog post we’ll add the connector logic. For now, let’s have a look at some of the details of the API:


If we access the URL via /rfc/description, this is the JSON code I get back:


  "connectors": [
      "name": "Machine Connectivity",
      "version": "0.1",
      "type": "com.bmc.example.jbconnectivity",
      "path": "jbconnectivity",
      "capabilities": [
      "activeConnectionInstances": [
          "id": "jbconnectivity-1",
          "name": "Production"
      "actions": [
          "name": "pingMachine",
          "displayName": "pingMachine",
          "path": "pingMachine",
          "inputs": [
              "name": "machineName",
              "type": "String",
              "required": true
          "outputs": [
              "name": "Result",
              "type": "String"
          "com.bmc.dsm.catalog": null


That’s enough for Catalog to identify the connector and add it to the workflow. Obviously, it won’t do anything as we haven’t defined any requests for the actions yet, but let’s add it anyway to see what it does:

The name is just for you to identify the server, notice that the URL uses the root. The username and password are used in case of Basic HTTP authentication. If you’re not using them, just enter some dummy values. If all goes well, the actions are added to the palette and I can use it in my workflow. You might have noticed the field Connection Instance Id which is a required field added automatically. This has to have the ID of the active connection instance (not the path) as defined in the descriptor, it needs to be an exact match, else the requests will be not be sent. In my example it’s jbconnectivity-1.


That takes care of the design, Catalog can read everything and we can start building our workflow.



But we’re not there yet, we haven’t anything defined that’s happening at run-time. When Catalog processes the workflow it executes the actions we defined, this results in Catalog sending out requests to our API and we need make sure the API responds appropriately. Here are the calls:


POST /{connector_path}/com.bmc.dsm.catalog:checkHealth


This is called periodically on each connection to verify its availability. The server is supposed to run a check to see if everything is okay and reports back to Catalog. An Administrator can trigger the check as well.


POST /{connector_path}/${action_path}


If the activity is executed, this call will go out. The action_path matches the path you defined in the description JSON for the respective action.


Let's look at this in more detail. checkHealth is a POST request so there’s a HTTP Body with the payload:


POST /jbconnectivity/com.bmc.dsm.catalog:checkHealth 

  "connectionInstanceId": "jbconnectivity-1",  
  "request": {}  


Notice that this isn't part of /rcf anymore. The server is supposed to check the connectionInstanceId (you defined this in description) and verify if everything is okay. Always respond with HTTP200 and with the following JSON:


  "connectionInstanceId": "jbconnectivity-1",
  "response": {
    "status": "CONNECTION_SUCCESS", //CONNECTION_FAILURE if there’s a problem.
    "message": null


Here’s how I coded this in the controller. To keep it simple I’m returning always CONNECTION_SUCCESS. We’ll work this out in more detail later.


@RequestMapping(value = "/jbconnectivity/com.bmc.dsm.catalog:checkHealth", method = RequestMethod.POST)
public String checkHealth() {

  JSONObject jsonResponse = new JSONObject();
  jsonResponse.put("status", "CONNECTION_SUCCESS");
  jsonResponse.put("message", JSONObject.NULL);

  JSONObject jsonHealth = new JSONObject();
  jsonHealth.put("connectionInstanceId", "DEV");
  jsonHealth.put("response", jsonResponse);

  return jsonHealth.toString();


Which leaves us with the connector actions. This is what my Ping action request looks like. This will be generated by Catalog:


POST /jbconnectivity/pingMachine

  "inputs": {
    "machineName": "clm-aus-12345"
  "connectionInstanceId": "jbconnectivity-1"


Notice again that there's no /rcf prefix. Catalog bases the values on the values of the input fields. What I need to do is respond with the following JSON:


  "outputs": {
    "result": "OK"


The exact format depends on what you defined in descriptor. I just have one field defined here, a field of type String called result.


Here’s the code in the controller. Again, the hardcoded values are purely for illustrative purpose. We’ll make this more dynamic in the next article.


@RequestMapping(value = "/jbconnectivity/pingMachine", method = RequestMethod.POST)
public String checkPing() {

  JSONObject jsonInputs = new JSONObject();
  jsonInputs.put("result", "OK");

  JSONObject jsonPing = new JSONObject();
  jsonPing.put("outputs", jsonInputs);

  return jsonPing.toString();


That’s all you need to get this working. My examples are all fairly straightforward but I hope you appreciate the flexibly and more importantly the possibilities the connector offers. It can be as simple as a TCP ping and as complicated as the front for a SOAP integration with a custom payroll system. The principles remain the same.


What would you do with Remote Server Integration? It’s very versatile, if you define the API correctly you can get it to execute your Java code. It doesn’t necessarily have to be a connection to an external system, it could also be an extension of the functionality. All you need to define are inputs and outputs.


The API we’ve written so far is basic and mostly contains hardcoded values, we’d needs to build the logic to get it to do anything. Let’s continue with the example we’ve been using so far: a network ping to determine if machines are alive or not. I’ve used this example before for an Innovation Suite action, let’s check how this would work for a Remote Server integration. But we need to leave this for the next article.


I am interested in your feedback. What do you think of the integration possibilities? Would you use this, does this article help you on your way? Maybe you have different or better use cases. I’d love to hear from you, leave a comment below.


Best Wishes,



Further Reading:

Share This:

Is this piece of Catalog workflow we have two possible outcomes. The first (long route) will create a Change Request and an Incident and the second (short route) will create just a Work Order. As you can see, we control the flow by using a number of exclusive gateways. In this example the users initial question response will determine the actual path. From the Remedy ITSM side the status of each fulfillment application is routed back by a combination of Remedy workflow and integration JAR file which is triggered by the remoteaction.bat file on the host of the AR Server.

The Catalog Remedy workflow & JAR file (along with the manager approval chain) is implemented by the Catalog ITSM integration patch which is available on our EPD site.

We use "Receive Task" here to listen for the fulfillment status and continue the flow (if required).

If the status isn't being sent back to the DWP Client, check the remoteaction.log and the SB:ServiceRequestStub form for errors on the AR Server.

To begin with, we create a number of input variables which will be used to map question responses to fields within each application. Another question is added here for workflow direction.


As you can see, the flow will only proceed on the branch defined if the highlighted condition is met. If any other answer is provided it will choose the other path.



Now that we've completed our design, we can start mapping our question responses in addition to manually setting all of other required fields. For the purposes of this example I'm only mapping the summary however we can of course create separate questions to map against all of the other fields ( just make sure to select the correct question type).

Don't forget to use the service Broker context variable for common fields !

We also need to set our Process Correlation ID to associate the request with the relevant fulfillment application in ITSM.


Once our Change request has completed, we need to add "Get Change Request by Identifiers" to collect it's identity.



To keep the end user (DWP Client) informed of what's going on we're using the CRQ ID from above to pass back to the request along with a custom message.

Remember, the status values need to match up to those defined in the enumeration table of our documentation (Setting the service request status).

Now that the status has been mapped to the request, we use "Receive Task" to stop the workflow and wait for a signal from the Change Request.


On the other side of the branch, our exclusive gateway will only allow an Incident to be created once the status (completed) has been received.



Once again, we need to collect information about our generated Incident for use in subsequent activities.



Just like the Change Request, here we're feeding back the status and another custom message along with the actual number of the generated incident.



We can leave the receive task parameter name as it is and use it for the same purpose as our Change Request.


Once the Incident has been "Resolved", we close the request in the Digital Workplace client and pass our custom message.

You could also use the actual Incident status reason for resolution from "Get Incident By Identifiers" here.



Finally, let's add our input questions and tie it all together. As you can see, I've added simple conditional questions to map the summary depending on the flow route.



Now let's submit the request choosing the "Long route" to generate our Change Request and Incident !



As you can see, the fulfillment activity has been mapped for each step of the way !



In summary, with just a few simple workflow actions we have provided a dynamic view of fulfillment application activity !


That's all for now but I'll be back with more workflow Blogs soon...


Happy new year to all !

Share This:
Share This:

Of course services are supposed to work correctly. After all, you designed them yourself, put a lot of thought into them. You did your homework and it shows: they look the way you want them to and they create work orders to set up new PCs, for example, or alert teams on infrastructure changes, initiate onboarding processes, even book your holidays requests.  You might even have the questions translated into various languages, from Welsh to Chinese. But something has gone amiss. The work order records are created, but they always show up with the wrong status. You check again, it’s definitely not you, everything looks right. What could it be? The whole service is down, and fixing it is time-critical. Tick tock.


Luckily for you, Catalog is pretty good at telling you what’s happening to those services your users are creating. I would maybe even go as far as to say that it’s really good at it. If your tool-of-choice is SRM you know that logs are difficult to avoid. The wrong status shows up in your request? Start with the combined SQL, API and Filter logs. Requests get stuck? Give me the combined SQL, API and Filter logs. The value for the Summary field not populated correctly? SQL, API and Filter logs will tell us why.


Is this any better in Catalog? As a matter of fact, it is. Logs have their place but it's not the place you start in Catalog. Not convinced? Let’s have a look. The core of your service is the workflow, this tells you how the questions provided by the end users are handled and, more importantly, how the backend process is fulfilled. This is where the work order records and incidents are created. Here’s my workflow:


myit-sb_Phaser bank alignment request (3).png


Looks pretty good, right? If my phaser banks are not aligned properly, my service will make sure the right team gets engaged straight away. Let’s create a request for the phaser relay on deck 47A:



dwpc blog 2 s 2.PNG


According to my workflow a few things should happen: a work order record should be created if the priority is deemed low or medium. If it’s high or critical a record should be submitted to the external senior command system for further evaluation. But there’s something going wrong here, when the work order is cancelled, the Catalog request does not reflect this and is still stuck in In Progress.


dwpc blog 2 s 3.PNG


How can you work out what’s happening? You need to look at the flow and understand how the service requests are handled. But the first step doesn’t have to be logs, it’s handled differently in Catalog. First things first, let’s have a look at the report with all the recent requests:


dwpc blog 2 s 4.PNG


Now go to the Actions menu and click on View Process. This will show you the workflow it’s currently processing. Here’s mine:







The activities with a dark grey border have been processed successfully, the activity with the green border is where we currently are. We can easily see that it informed the security maintenance team, then navigated the gateway to create the work order. This also was successful, but it’s still stuck at Wait for Completion.

This now allows me to see what values are passed between the activities. If I click on Create Work Order I can see the output:


  "instanceId": "AGGAA5V0FLH5PAP9WE46P8ZAJTDPZ3",
  "requestId": "000000000000611",
  "workOrderId": "WO0000000001016"


It’s creating the work order record correctly and looking at it I can see it’s already cancelled, so I need to look at the workflow in more detail. The Wait for Completion construction is basically a loop which pauses the workflow until it meets the condition. So let’s have a look at the variable that’s used for this. I can do this via the tab with the gear icon:


dwpc blog 2 s 6.PNG


That should match my condition. Let’s go back to the original workflow and double check this:


dwpc blog 2 s 7.PNG


So there’s our problem, my condition used the American spelling (one L) whereas ITSM favours British spelling (two Ls). It never meets this condition so we’re stuck in the loop.


I realise this is a fairly straightforward root cause but I hope you appreciate it didn’t take us long to find it. Using the graphical overview of the workflow process we quickly established the flow and the point where it got stuck. From there onwards we were able to work out what the various variable values were which allowed us to concentrate on the reason why it’s not progressing.


But what if looking at the workflow isn’t enough? What if this doesn’t explain why it’s not processing? What if you need to go deeper? There’s always the option to go through the logs. Catalog’s main log file is bundle.log which is generated in the db folder. This will record the service requests from DWP with all the values but it won’t track the workflow process. So you can find the JSON code generated by the DWP request with all the values and the ID of the request but not what’s happening afterwards. It will however record any exception that might occur. We are planning to introduce some dedicated process logs in a future release which will allow us to track the workflow processes via logs. As soon as this is available I’ll dedicate another blog article to debugging your workflow processes via logs, so stay tuned!


But at least I hope this gives you some idea how to get started when there’s a problem with the workflow processes. The visual approach allows you to quickly assess the point where its stuck before you drill down into more details. So the next time your services don’t quite behave the way you expect them to, you know where to look. And if you’re stuck? Well, you just have to give us a shout.


Best wishes,


Share This:

Out of the box the Remedy connector presents a number of common fields to map to a fulfillment application but what if your Remedy ITSM application has been customized ? Well, this is where the other remedy connector actions come into play. In this Blog I'll cover how we can pass question responses to custom fields within BMC Remedy Incident Management. I'll also describe passing Incident notes to the Request in the Digital Workplace Client. The same principle applies to all BMC Remedy ITSM applications.


The overall workflow is designed by using a combination of elements as illustrated below.




First of all, add your custom fields into the "HPD:Help Desk" & "HPD:IncidentInterface" forms.



Now add the same fields into the "HPD:IncidentInterface_Create" form and update the push fields action of the "HPD:HII:CreateIncident_100`! Filter". I'm using a text and drop-down type  question here.


Don't forget to flush the Mid-Tier cache and update the fields with the correct permissions !

Now we're ready to begin building our workflow. In this example I'm going to create four text questions and one context type, the context variable is used to pass common field values. This saves you the trouble of creating unnecessary questions for mapping.




The following table is used to describe each action.


Create Incident with IdentifiersCreate an incident with identifying variables for use in subsequent activities.
Get Incident by IdentifiersCollect information about the generated Incident
Build Input SetBuild custom fields
Set EntryUpdate Remedy form with custom fields
Receive TaskWait for a response
Set Service Request Status

Change the Request Status in the Digital Workplace Client


After we've moved our actions to the canvas we begin mapping possible field values while determining the best flow for our questionnaire. In this example I'm mapping "Describe the Incident" question (input variable) to the "Summary" field, "Impact field" to the Incident Impact and two questions to my custom fields of the Incident. The Correlation ID is used by the workflow to route values from an external system and match within the Catalog.


For the workflow to understand the relevant Incident details, we map the values from the data collected with "Create Incident with Identifiers"


With "Build Input Set" my key values represent the actual custom field names from the "HPD:Help Desk" form.



Now that we have our Incident identity and custom fields, we're ready to map these values with "Set Entry" to the "HPD:IncidentInterface" form.


At this point the workflow has created the Incident along with the responses for the "Summary", "Impact" and custom field values. We use receive task here to block the flow until our "Resolved" status has been returned from the Incident itself. The exclusive gateway allows us to control the flow and continue when "Work Status" = Resolved.


Now, let's collect the new Incident values from the generated Incident by using "Get Incident with Identifiers" again.


Optionally, we can pass the end users Incident Notes values to the status reason field and close the Request

There are may other useful fields to choose form "Get Incident by Identifiers" such as "Status Reason" which would map the users status value before they "resolved" the Incident.


Now I'm ready to build my questionnaire for the above questions.



Now let's see the complete flow in action by submitting the Request !



Watching the transitions, we can see the status moving to "Closed" and the Incident Management users notes update being passed back to the Request.




Stay tuned as I'll be updating this space with more examples soon...

Share This:

BMC Digital Workplace 18.11 is now available. This release introduces even more enhancements to end user experience as well as additional catalog capabilities.


All of the following enhancements are available for BMC Digital Workplace Advanced. Enhancements marked with an asterisk (*) are also available for BMC Digital Workplace Basic.


Dependent services


Define prerequisite services by mapping dependencies.

Add collaborators to Requests


Define Collaborators to view, edit and delete a Request.



Assign actions to class attributes


Add conditions to restrict the number of assets associated with a Service Action.

Questionnaire enhancements


Return additional fields based on fixed or dynamic responses to a question.


Use action triggers to display responses based on Dynamic lookup questions.

Reassign Approvals*


Send requests to other business users for approval.

Clear multiple notifications*


Remove all notifications from both the Digital Workplace Client and Catalog.



Connector Development


Develop custom (on-premise) connectors to transfer data to and from external systems via REST calls.   





For version details of Remedy ITSM Remedy AR System  HR Case ManagementClient ManagementAtrium CMDB Cloud Lifecycle Mgmt please refer to our Compatibility Matrix.

Next Steps


For a comprehensive summary of all enhancements please refer to our Digtal Workplace Advanced and Basic documentation.

Share This:

BMC Digital Workplace 18.08 is now available ! In this release we’re continuing to focus on new features to improve end-user experience.


All of the following enhancements are available for BMC Digital Workplace Advanced. Enhancements marked with an asterisk (*) are also available for BMC Digital Workplace Basic.



Multi-user requests


Quickly submit a request on behalf of multiple users.




Alternate Approver*


Select an alternate approver from the Digital Workplace Client.



Choose time/date interval or edit current setting.



Appover assignee will also receive an In App Notification.



My Stuff impersonation


Launch asset actions on behalf of someone else.




Search logic*


Configure search logic for services and knowledge articles





Quick requests


Bypass the Request profile page by enabling "Quick request".




Save for later


Save individual Requests for later submission.

Checkout flow


Change "On behalf of" or Quantity in the checkout flow.




Workflow Designer


Manipulate text using "String Utils" and return multiple records with "Get Entry by Queries".




Search Catalog requests by submitted answers


We can now also search catalog requests based on question response.





Innovation Suite views


Cross launch into an Innovation Suite application.



User Profile Synchronization*


Job title is transparently synchronized into your DWP Profile.



Sub-catalog for business units


Add a Sub-catalog and assign internal supplier or Administrator roles.






Broadcasts from ITSM or Smart IT are now also visible within Digital Workplace.




Search filter names


Rebrand results filter tabs.


New filters are immediately visible on search.





Customize the client without coding ability.







For version details of Remedy ITSM Remedy AR System  HR Case ManagementClient ManagementAtrium CMDBCloud Lifecycle Mgmt please refer to our Compatibility Matrix.



Next Steps


For a comprehensive summary of all enhancements please refer to our Digtal Workplace Advanced and Basic documentation.

Share This:

We are pleased to announce BMC Digital Workplace 18.05 is generally available and packed with new features !



*All features are applicable to Digital Workplace Advanced with the exception of the three levels of browse categories.


Simplified Architecture


  • Digital Workplace and SmartIT are now separate installers.
  • MongoDB and node.js (MyITSocial) has been removed.
  • Social data is now stored on the Digital Workplace RDBMS (Oracle & SQL).

Digital Workplace 18.05 is a required upgrade before any later releases. If you would like to upgrade to 18.08 when it's released you must first upgrade to DWP 18.05. There is no ability to skip this upgrade if you would like to move to later releases.


Save Multiple Carts


Save Carts for a later checkout.

Large Subcategory view


Subcategories now include a larger view.

Third Tier Category


Browse through three levels of Categories.

Remedy with Smart IT Integration


Comments to Catalog Requests will be reflected in their associated fulfillment applications and visa versa. Digital Workplace Requests are also visible within Smart IT.

Asset Management Integration


Leverage BMC Asset Management to view and action on Assets (CI's).


Owned Assets are visible under the "MyStuff" tab.

Add Classes to Asset Groups


Create Asset Groups and retrieve data from BMC Asset Management.

Create Asset Action questions using data from Asset Management


Data retrieved from BMC Asset Management can also be used wihthin Asset Actions.

As soon as the Action is launched, questions are populated from the relevant form within BMC Asset Management !

Amazon Web Services Catalog



Import services from the AWS Service Catalog.


Submit as a Request in the Digital Workplace Client.



Chatbot Requests


Enable Chatbot for a Request in the Catalog.

Automatically create the Request in Digital Workplace via Chatbot.

Search for submitted answers


Retrieve a Service Request based on question response.

Remove services from My Stuff


Remove unwanted services from the My Stuff tab.

Export and import Translated Services



Quickly localize a service by exporting and re-importing again.

View and edit imported Workflow


View imported workflow from BMC Service Request Management and add other activities.


View Workflow Relationship

Quickly check what questionnaires and services are related to workflow.



We now provide an xarchive binary file which you can open in the re-branding tool and create an IPA mobile application. You must sign this file using the rebranding tool and your digital cert from Apple.



For version details of Remedy ITSM Remedy AR  System Atrium Orchestrator HR Case ManagementClient ManagementAtrium CMDBCloud Lifecycle Mgmt please refer to the Digital Workplace Basic and Advanced Compatibility Matrix for further details.



Next Steps


For a comprehensive summary of all enhancements please refer to our documentation.


Please comment with your favorite feature

Filter Blog

By date:
By tag: