Creating a Custom Middleman

Overview Getting Started Downloads GitHub Repository
Search…
When it comes to creating a custom middleman, the sky is the limit as far as options for how to implement your middleman are concerned. Unlike custom triggers and completion handlers, there is very little structure that defines how your middleman must be implemented. More specifically, custom triggers and completion handlers must be written as node modules and must implement and export specific functions in order to work correctly, whereas a custom middleman can be written in any coding language that enables you to communicate with your serializer and your trigger. Assuming that you are not replacing the SitecoreUML Service for Sitecore component (which satisfies the serializer role), this means that so long as your language can communicate with the trigger and can make an HTTP GET to the SitecoreUML Service then your middleman should work.
If you decide to create a custom middleman, it is more than likely that you will want to create a custom trigger, as well. For example, you may want to make a middleman that performs all communication with SitecoreDXG through web requests. In this case, you may choose to create a new trigger that exposes an ExpressJS service (or you could build off of the example ExpressJs that is included with SitecoreDXG), and write your custom middleman as a PowerShell script, or as part of an application written in C#, Java, Bash, C++, PHP, C, Lisp, ... and so on.
Requirements of a Middleman
At a minimum, a middleman must be able to satisfy the following responsibilities:
Retrieving the serialized Sitecore template architecture from the serializer (the SitecoreUML Service for Sitecore, by default)
Forwarding the response from the serializer to the trigger
In addition to the above, the native RabbitMQ middleman also includes support for adding completion handler data to the serialized response before passing it along to the trigger. Doing so will enable you to specify the completion handler(s) and settings to be used for each specific execution. If your middleman is being used to integrate with a CI/CD tool, for example, this means that you can have unique setting per build/environment, and beyond. As such, it's best practice for middlemen to also include support for adding completion handler data to the serialized response.
Example
The below example shows the default RabbitMQ Middleman that is included with SitecoreDXG. Feel free to use this as a starting point when writing your own handlers.
1
#!/usr/local/env node
2
​
3
/*
4
 * Copyright (c) 2018 Zachary Kniebel. All rights reserved.
5
 *
6
 * NOTICE:  All information contained herein is, and remains the 
7
 * property of Zachary Kniebel. The intellectual and technical 
8
 * concepts contained herein are proprietary to Zachary Kniebel and
9
 * may be covered by U.S. and Foreign Patents, patents in process, 
10
 * and are protected by trade secret or copyright law. Dissemination 
11
 * of this information or reproduction of this material is strictly 
12
 * forbidden unless prior written permission is obtained from Zachary
13
 * Kniebel ([email protected]).
14
 *
15
 */
16
​
17
/* DEPENDENCIES */
18
​
19
// third-party
20
const amqp = require('amqplib/callback_api');
21
const request = require('request');
22
​
23
/* EXECUTION */
24
​
25
/**
26
 * Optionally closes the connection and exits with the given exit code
27
 * @param {object} process process object to exit
28
 * @param {integer} exitCode exit code value to be passed upon exiting  
29
 * @param {object} connection (optional) connection to be closed
30
 */
31
var _exitProgram = function(process, exitCode, connection) {
32
    if (connection) {
33
        connection.close(); 
34
    }
35
​
36
    process.exit(0);
37
};
38
​
39
​
40
var args = process.argv.slice(2);
41
var connectionString = args[0];
42
​
43
if (!connectionString) {
44
    console.log("No connectionString was passed. Program terminating without sending.");
45
    return;
46
}
47
​
48
amqp.connect(connectionString, function(err, conn) {
49
    // create a channel
50
    conn.createChannel(function(err, ch) {
51
        var jsonGetUrl = args[1];        
52
        if (!jsonGetUrl) {
53
            console.log("No jsonGetUrl was passed. Program terminating without sending.");
54
            _exitProgram(process, 1, conn);
55
            return;
56
        }
57
​
58
        var queue = args[2];     
59
        if (!queue) {
60
            console.log("No queue was passed. Program terminating without sending.");
61
            _exitProgram(process, 1, conn);
62
            return;
63
        }
64
​
65
        request(jsonGetUrl, (err, res, data) => {
66
            if (err) { 
67
                return console.error(err); 
68
                _exitProgram(process, 1, conn);
69
            }
70
​
71
            var json = JSON.parse(data);
72
            if (!json.Success) {
73
                console.error("An error occurred while retrieving the architecture data. Program terminating...", json);
74
                _exitProgram(process, 1, conn);
75
            }            
76
            if (args.length > 3) {
77
                var completionHandlers = args[3];
78
                json.Data.CompletionHandlers = JSON.parse(completionHandlers);
79
                data = JSON.stringify(json);
80
            }
81
​
82
            console.log("Architecture data received. Forwarding to generation_queue...");
83
            ch.assertQueue(queue, {durable: false});
84
            ch.sendToQueue(queue, Buffer.from(data));
85
            console.log(" [x] Sent %s bytes to the generation_queue", data.length);
86
​
87
            setTimeout(function() { _exitProgram(process, 0, conn) }, 500);
88
        });
89
    });
90
});
Copied!
How To - Previous
Creating a Custom Completion Handler
Next - How To
Viewing Helix Validation Errors
Last modified 3yr ago
Copy link
Contents
Requirements of a Middleman
Example