\n$ psg tail | grep -v gawk
\n PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
\n<nothing>
\n<\/code>
\nFrom now on, until the aggregation is turned back on, this list will be empty as no new tail commands will be started.
\nThe number of tail commands grows and shrinks as expected, so the process clean up is working.
\nThe agentexec.log file is often here because jobs are started frequently and therefore this file regularly triggers the MODIFY event. dmadmin and sysadmin owned session logs come and go for each started job. The DataDictionaryPublisherDoc.txt, bpm_XCPAutoTaskMgmtDoc.txt and Initialize_WQDoc.txt are a few followed job’s logs.
\nIn the used test system, an out of the box docbase without any running applications, the output is obviously very quiet with long pauses in between but it can become extremely dense in a busy system. When investigating problems in such systems, it can be useful to redirect the whole output to a text file and use one’s favorite editor to search it at leisure. It is also possible to restrict it to an as narrow as desired time window (if docker logs is used) in order to reduce its noise, exclude files from being watched (see the next paragraph) and even to stop aggregating new logs via the $tail_on_off file so only the currently ones are followed as long as they are active (i.e. written in).<\/p>\nDynamically reconfiguring inotifywait via a parameter file<\/h2>\n
In the preceding examples, the inotifywait command has been passed a fixed, hard-coded subtree name to watch. In certain cases, it could be useful to be able to watch a different, random sub-directory or list of arbitrary files in unrelated sub-directories with a possible list of excluded files; for even more flexibility, the other inotifywait’s parameters could also be changed dynamically. In such cases, the running inotifywait command will have to be stopped and restarted to change its command-line parameters. One could imagine to check a communication file (like the $tail_on_off file above) inside the entrypoint’s main loop, as shown below. Here the diff is relative to the precedent static parameters version:<\/p>\n
\n10a11,13\n> # file that contains the watcher's parameters;\n> export new_inotify_parameters_file=${watcher_workdir}\/inotify_parameters_file\n> \n15a19,20\n> inotify_params=\"$1\"\n> \n19c24\n eval $private_inotify ${inotify_params} $watcher_workdir | gawk -v tail_timeout=$((tail_timeout * 60)) -v excluded_files=\"$excluded_files\" -v bMust_tail=1 -v tail_on_off=$tail_on_off -v heartbeat_file=$heartbeat_file -v env_private_tail=private_tail -v FS=\"|\" -v Apo=\"'\" 'BEGIN {\n122a128,142\n> process_new_inotify_parameters() {\n> # read in the new parameters from file $new_inotify_parameters_file;\n> # first line of the $new_inotify_parameters_file must contains the non-target parameters, e.g. -m -e create,modify,attrib -r --timefmt \"%Y\/%m\/%d-%H:%M:%S\" --format \"%T %e %w%f\";\n> new_params=$(cat $new_inotify_parameters_file)\n> rm $new_inotify_parameters_file\n> \n> # kill current watcher;\n> pkill -f $private_inotify\n> \n> # kill the current private tail commands too;\n> pkill -f $private_tail\n> \n> # restart inotify with new command-line parameters taken from $new_inotify_parameters_file;\n> follow_logs \"$new_params\" &\n> }\n138,139c158,162\n< # start the watcher;\n # default inotifywait parameters;\n> # the creation of this file will trigger a restart of the watcher using the new parameters;\n> cat - < $new_inotify_parameters_file\n> --quiet --monitor --event create,modify,attrib --recursive --timefmt \"%Y\/%m\/%d-%H:%M:%S\" --format '%T|%e|%w%f' ${DOCUMENTUM}\/dba\/log --exclude $new_inotify_parameters_file\n> eot\n143a167\n> [[ -f $new_inotify_parameters_file ]] && process_new_inotify_parameters\n<\/pre>\nTo apply the patch, save the first listing into a file, e.g. inotify_static_parameters.sh, the above diff output into a file, e.g. static2dynamic.diff, and use the command below to create the script inotify_dynamic_parameters.sh:
\n
\npatch inotify_static_parameters.sh static2dynamic.diff -o inotify_dynamic_parameters.sh
\n<\/code>
\nIn order not to trigger events when it is created, the $new_inotify_parameters_file must be excluded from inotifywait’s watched directories.
\nIf, for instance, we want later to exclude jobs’ logs in order to focus on more relevant logs, we could use the following inotifywait’s parameters:<\/p>\n\n# cat - <<-eot > $new_inotify_parameters_file\n --quiet --monitor --event create,modify,attrib --recursive --timefmt \"%Y\/%m\/%d-%H:%M:%S\" --format \"%T|%e|%w%f\" ${DOCUMENTUM}\/dba\/log --exclude '${DOCUMENTUM}\/dba\/log\/dmtest\/agentexec\/job_.*' --exclude $new_inotify_parameters_file\neot\n<\/pre>\nFrom the outside of a container:<\/p>\n
\ndocker exec <container> \/bin\/bash -c 'cat - < $new_inotify_parameters_file\n --quiet --monitor --event create,modify,attrib --recursive --timefmt \"%Y\/%m\/%d-%H:%M:%S\" --format \"%T|%e|%w%f\" ${DOCUMENTUM}\/dba\/log --exclude \"${DOCUMENTUM}\/dba\/log\/dmtest\/agentexec\/job_.*\" --exclude $new_inotify_parameters_file\neot\n'\n<\/pre>\nwhere the new option −−exclude specifies a POSIX-compliant regular expression to be quoted so the shell does not perform its variable expansions.
\nAfter at most $pause_duration seconds, this file is detected (line 34), read (line 14), deleted (line 15) and the current watcher gets restarted in the background with the new parameters (line 24).
\nThis approach is akin to polling the parameter file and it looks a bit unsophisticated. We use events to control the tailing through the $tail_on_off file and for the heartbeat. Why not for the parameter file ? The next paragraph will show just that.<\/p>\n
Dynamically reconfiguring inotifywait via an event<\/h2>\n
A better way would be to use the watcher itself to check if the parameter file has changed ! After all, we shall put our money where our mouth is, right ?
\nIn order to do this, and dedicated watcher is set up to watch the parameter file. For technical reasons (in order to watch a file, that file must already exist. Also, when the watched file is erased, inotifywait does not react to any events on that file any longer; it just sits there idly), instead of watching $new_inotify_parameters_file, it watches its parent directory. To avoid scattering files in too many locations, the parameter file will be stored along with the technical files in ${watcher_workdir} and, in order to avoid impacting the performance, it will be excluded from the main watcher (parameter –exclude $new_inotify_parameters_file, do not forget to append it otherwise the main watcher will raise events for nothing; it should not impede the parameter file to be processed though).
\nWhen a MODIFY event on this file occurs, which includes a CREATE event if the file did not pre-exist, the event is processed as shown precedently.
\nHere the diff compared to the preceding polled parameter file version:<\/p>\n
\n143a144,151\n> # the parameter file's watcher;\n> param_watcher() {\n> IFS=\"|\"\n> inotifywait --quiet --monitor --event create,modify,attrib --timefmt \"%Y\/%m\/%d-%H:%M:%S\" --format '%T|%e|%w%f' $watcher_workdir --exclude $tail_on_off $heartbeat_file | while read timestamp event target_file; do\n> [[ $target_file == $new_inotify_parameters_file ]] && process_new_inotify_parameters\n> done\n> }\n> \n162a171,173\n> \n> # starts the parameter file's watcher;\n> param_watcher &\n<\/pre>\nThe delta is quite short with just the function param_watcher() to start the watcher on the parameter file and process its signal by invoking the same function process_new_inotify_parameters() introduced in the polling version.
\nTo apply the patch, save the above diff output into a file, e.g. dynamic2event.diff, and use the command below to create the script inotify_dynamic_parameters_event.sh from the polling version’s script inotify_dynamic_parameters.sh created above:
\n
\npatch inotify_dynamic_parameters.sh dynamic2event.diff -o inotify_dynamic_parameters_event.sh
\n<\/code>
\nThe dedicated watcher runs in the background and restarts the main watcher whenever the latter receives new parameters. Quite simple.<\/p>\nDynamically reconfiguring inotifywait via signals<\/h2>\n
Yet another way to interact with inotifywait’s script (e.g. the container’s entrypoint) could be through signals. To this effect, we’ll need first to choose suitable signals, say SIGUSR[12], define a trap handler and implement it. And while we are at it, let’s also add switching the watcher on and off, as illustrated below:<\/p>\n
\n2a3,5\n> trap 'bounce_watcher' SIGUSR1\n> trap 'toggle_watcher' SIGUSR2\n> \n7a11,14\n> # new global variable to hold the current tail on\/off status;\n> # used to toggle the watcher;\n> export bMust_tail=1\n> \n144,149c151,162\n< # the parameter file's watcher;\n< param_watcher() {\n< IFS="|"\n< inotifywait --quiet --monitor --event create,modify,attrib --timefmt "%Y\/%m\/%d-%H:%M:%S" --format '%T|%e|%w%f' $watcher_workdir --exclude $tail_on_off $heartbeat_file | while read timestamp event target_file; do\n< [[ $target_file == $new_inotify_parameters_file ]] && process_new_inotify_parameters\n # restart the watcher with new parameters;\n> bounce_watcher() {\n> [[ -f $new_inotify_parameters_file ]] && process_new_inotify_parameters\n> echo \"parameters reloaded\"\n> }\n> \n> # flip the watcher on\/off;\n> # as file $tail_on_off is watched, modifying it will trigger the processing of the boolean bMust_tail in the gawk script;\n> toggle_watcher() {\n> (( bMust_tail = (bMust_tail + 1) % 2 ))\n> echo $bMust_tail > $tail_on_off\n> echo \"toggled the watcher, it is $bMust_tail now\"\n172,173c185,187\n< # starts the parameter file's watcher;\n process_new_inotify_parameters\n> \n> echo \"process $$ started\"\n178d191\n< [[ -f $new_inotify_parameters_file ]] && process_new_inotify_parameters\n<\/pre>\nTo apply the patch, save the above diff output into a file, e.g. event2signals.diff, and use the command below to create the script inotify_dynamic_parameters_signals.sh from the event version’s script inotify_dynamic_parameters_event.sh created above:
\n
\npatch inotify_dynamic_parameters_events.sh event2signals.diff -o inotify_dynamic_parameters_signals.sh
\n<\/code>
\nThe loop is simpler now as the functions are directly invoked by outside signals.
\nTo use it, just send the SIGUSR[12] signals to the container, as shown below:
\n
\n# write a new configuration file:
\n...
\n# and restart the watcher:
\n$ docker kill --signal SIGUSR1 <container>
\n
\n# toggle the watcher;
\n$ docker kill --signal SIGUSR2 <container>
\n<\/code>
\nIf testing outside a container, the commands would be:
\n
\n\/bin\/kill --signal SIGUSR1 pid<\/em>
\n# or:
\n\/bin\/kill --signal SIGUSR2 pid<\/em>
\n<\/code>
\nwhere pid<\/em> is the pid displayed when the script starts.
\nWe won’t indulge more on signals, see How to stop Documentum processes in a docker container, and more (part I)<\/a> for many more examples of using signals to talk to containers.<\/p>\nConclusion<\/h2>\n
inotifywait is simple to configure and extremely fast, pratically instantaneous, at sending notifications. Although the aggregated output looks a bit confusing when the system is loaded, there are several ways to reduce its volume to make it easier to use. It is an interesting addition to an administrator to help troubleshooting repositories and their client applications. With suitable parameters, it can be used to support any containerized or traditional installations. It is one of those no frills tools that just work (mostly) as expected. If you ever happen to need a file watcher, consider it, you won’t be disappointed and it is fun to use.<\/p>\n","protected":false},"excerpt":{"rendered":"
Testing the log watcher This is part II of the article. Part I is here. All the above code has to be included in the entrypoint script so it gets executed at container start up time but it can also be tested more simply in a traditional repository installation. First, we’ll move the code into […]<\/p>\n","protected":false},"author":40,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[525],"tags":[],"type_dbi":[],"class_list":["post-13359","post","type-post","status-publish","format-standard","hentry","category-enterprise-content-management"],"acf":[],"yoast_head":"\n
Tracking Logs Inside a Documentum Container (part II) - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Tracking Logs Inside a Documentum Container (part II)\" \/>\n<meta property=\"og:description\" content=\"Testing the log watcher This is part II of the article. Part I is here. All the above code has to be included in the entrypoint script so it gets executed at container start up time but it can also be tested more simply in a traditional repository installation. First, we’ll move the code into […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2020-01-29T23:45:31+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-10-24T07:32:08+00:00\" \/>\n<meta name=\"author\" content=\"Middleware Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Middleware Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"16 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/tracking-logs-inside-a-documentum-container-part-ii\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/tracking-logs-inside-a-documentum-container-part-ii\\\/\"},\"author\":{\"name\":\"Middleware Team\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d8563acfc6e604cce6507f45bac0ea1\"},\"headline\":\"Tracking Logs Inside a Documentum Container (part II)\",\"datePublished\":\"2020-01-29T23:45:31+00:00\",\"dateModified\":\"2025-10-24T07:32:08+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/tracking-logs-inside-a-documentum-container-part-ii\\\/\"},\"wordCount\":1310,\"commentCount\":0,\"articleSection\":[\"Enterprise content management\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/tracking-logs-inside-a-documentum-container-part-ii\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/tracking-logs-inside-a-documentum-container-part-ii\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/tracking-logs-inside-a-documentum-container-part-ii\\\/\",\"name\":\"Tracking Logs Inside a Documentum Container (part II) - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2020-01-29T23:45:31+00:00\",\"dateModified\":\"2025-10-24T07:32:08+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d8563acfc6e604cce6507f45bac0ea1\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/tracking-logs-inside-a-documentum-container-part-ii\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/tracking-logs-inside-a-documentum-container-part-ii\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/tracking-logs-inside-a-documentum-container-part-ii\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Tracking Logs Inside a Documentum Container (part II)\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d8563acfc6e604cce6507f45bac0ea1\",\"name\":\"Middleware Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g\",\"caption\":\"Middleware Team\"},\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/author\\\/middleware-team\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Tracking Logs Inside a Documentum Container (part II) - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/","og_locale":"en_US","og_type":"article","og_title":"Tracking Logs Inside a Documentum Container (part II)","og_description":"Testing the log watcher This is part II of the article. Part I is here. All the above code has to be included in the entrypoint script so it gets executed at container start up time but it can also be tested more simply in a traditional repository installation. First, we’ll move the code into […]","og_url":"https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/","og_site_name":"dbi Blog","article_published_time":"2020-01-29T23:45:31+00:00","article_modified_time":"2025-10-24T07:32:08+00:00","author":"Middleware Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Middleware Team","Est. reading time":"16 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/"},"author":{"name":"Middleware Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1"},"headline":"Tracking Logs Inside a Documentum Container (part II)","datePublished":"2020-01-29T23:45:31+00:00","dateModified":"2025-10-24T07:32:08+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/"},"wordCount":1310,"commentCount":0,"articleSection":["Enterprise content management"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/","url":"https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/","name":"Tracking Logs Inside a Documentum Container (part II) - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2020-01-29T23:45:31+00:00","dateModified":"2025-10-24T07:32:08+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/tracking-logs-inside-a-documentum-container-part-ii\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Tracking Logs Inside a Documentum Container (part II)"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1","name":"Middleware Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g","caption":"Middleware Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/middleware-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/13359","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/40"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=13359"}],"version-history":[{"count":1,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/13359\/revisions"}],"predecessor-version":[{"id":41178,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/13359\/revisions\/41178"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=13359"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=13359"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=13359"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=13359"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}