Your Process is most likely using ..SendRequestAsync() to send to the Operation and has "pResponseRequired" set to 1 (or not set at all, so it's using the default value of 1).

There's nothing inherently wrong with this, but if you just want to send to the Operation and not worry about the response going back to your process, you could change the "pResponseRequired" flag to 0 in your call. So it would look a little like this:

Set tSC = ..SendRequestAsync("TargetOperationName",ObjToSend,0)

However you may wish to consider if this approach is appropriate to your setup, or if you would be better off using "SendRequestSync()" and dealing with the response synchronously. 

To parse the json, the below is a starting point for taking the content of the stream into a dynamic object, and then saving the value into its own variable.

Set DynamicObject=[].%FromJSON(pRequest.Stream)
Set Name = DynamicObject.name
Set DOB = DynamicObject.DOB
Set SSN = DynamicObject.SSN

You could then store these wherever you need to. If your SQL table is external, then you could have your Operation using the SQL Outbound Adapter to then write these in your external DB.

ETA: If you then need to pick out the values within the content of name (which I assume has come from a HL7 message) you could use $PIECE to pick out the data from the delimited string you're receiving.

Hey Daniel.

As a starting point, I would not be adding the trace when viewing the DTL in Studio, and instead I would add it when using the Data Transformation Builder:

Which gives me:

If this is not working for you, make sure that the router has "Log Trace Events" enabled in the router settings and the router has been restarted since enabling the trace. I have been caught out numerous times enabling the trace and then forgetting to restart the process/router in the production.

The issue of no results being returned is likely elsewhere in your query.

To test this, I created a basic table with the following:

And I then added a few rows:

This then gave me a table that looks like this (note that the double single quotes used in the insert are inserted as a single quotes into the table):

If I then run a query using the like function:

And if I want to exclude the inactive location:

The use of doubling up a single quote to escape the character is not a Intersystems specific approach, but is generally a standard SQL way of escaping the single quote.

That just means you're one step closer to solving the issue!

What are the data types for each field you're attempting to insert into?

Have you tried just inserting a row with just 1 of the fields populated? Something like:

INSERT INTO Phu_Replay_Schema.ReplayMessageModel (Completed) VALUES (1)

Hey Lewis.

Could you try swapping out "true" for it's bool equivalent? So try:

INSERT INTO Phu_Replay_Schema.ReplayMessageModel (Completed, MessageHeaderId, NewHeaderId, NewTargetName) VALUES (1, 3616, null, 'Router_ReplayHL7')

Hey Ciaran.

To overcome the issue of multiple ORCs overwriting your PIDgrp NTE in your copy, you will likely need to maintain a separate count of what is being copied over.

So you could look to do something similar to: (pay specific attention to actions 2, 9, and 10) 

Which would then give the following result:

You could then take it a step further by setting the value of your PIDgrp NTE to your count value before incrementing it:

Which would then give you:

As a warning, I did find that the DTL building went a bit weird when it comes to the auto-applying of the key counts. So I was adding a For Each on a repeating field and it assigned a key of say k1, then when adding the sets within the for each loop, it would randomly use k2 or k3 in the field. it might just be a limitation of how I was building things up, but it's one to keep an eye out for as it'll give you unexpected results if it happens to you. Good luck :)

Hey Ephraim.

I have thrown together a task which should do what you need. The code is a bit verbose and could be cut down a touch, but hopefully it's human readable enough for you to pick out what its doing.

Effectively, it takes the current date to then grab a date from last month, and then gets the first and last date of that month to then use in the audit method.

Class Demo.Tasks.MonthlyAudit Extends %SYS.Task.Definition
{

Method OnTask() As %Status
{
    Set tSC = $$$OK

    //Get Current Date
    Set CurentDatetime = $ZDATETIME($HOROLOG,3)

    //The report needs to be for last month, so get a date from last month based on todays date
    Set LastMonth = $SYSTEM.SQL.DATEADD("MM",-1,CurentDatetime)

    //Get last Day of last month As Horolog
    Set LastDayHoro =  $SYSTEM.SQL.LASTDAY(LastMonth)

    //Convert Horolog into a Date
    Set LastMonthEnd = $ZDATETIME(LastDayHoro,3)

    //Get First Day of Last Month
    Set LastMonthStart = $SYSTEM.SQL.DATEPART("YYYY",LastMonthEnd)_"-"_$SYSTEM.SQL.DATEPART("MM",LastMonthEnd)_"-01"

    //Switch to the %SYS Namespace
    ZNspace "%SYS"

    Set tSC = ##class(%SYS.Audit).Export("AuditExport.xml",,,LastMonthStart_" 00:00:00",LastMonthEnd_" 23:59:59")

    Quit tSC
}

}

Then, when setting the task up, I would set it to run on the first Monday of the Month, and it will grab everything from the previous month.

I believe the privilege comes from the OS user that is launching Terminal.

Have you tried running Terminal as an Admin and seeing if runs as expected?

Hey Kurro.

You should be able to include the allowed source in the rule constraint:

Alternatively, you could add a rule above that looks like this: