It might be as simple as formatting your calculated start & end date tokens you are placing in your xml. if you don't want to use UserParameters e.g. @Value($(StartDate)) you could use a DateTimeStamper and calculate today's date and format your date tokens from 20190228 into %m/%d/%Y using an AttributeManager setup

This will provide you with dates in the format your SOAP call is expecting. I'm guessing materializing the date or the formatting is fighting back.

Try this against a date token

@DateTimeFormat(@Evaluate(@Value(_datestamp),-8),%m/%d/%Y) and play with date formats you need in your valid SOAP call.

if you use an XMLTemplater to assemble your SOAP block (or is that a SOAP Bar, haha)

you can call the the attributes into the XML root epressoin such as

<StartDate>{fme:get-attribute("_date_minus8")}</StartDate>

<EndDate>{fme:get-attribute("_date_minus2")}</EndDate>

Scyphers

Thanks for getting me back on the right road.

1. I added a DateTimeStamper, using the _dateStamp in the Result Attribute.

2. I then added the Attribute Manager

Problem is that that Inspector displays the features as

date_minus8 calculated todays date

date_minus2 calculated todays date

3. I am then forwarding this into the SS911_Traffic_Accident (HTTPCaller) - Upload Body

4. Problem is

The fme:get-attribute() is an XQuery function defined for XQuery (sometimes called XML template depending on the context) expressions which can be executed only with XML transformer such as the XMLTemplater. If you would use the function, perform the expression with the XMLTemplater, as @scyphers suggested.

Takahasi

I added in the XMLTemplater, but still ending up with the same results.

Datestamp = 2019030112045...

_date_minus8 = 03/01/2019

_date_minus2 = 03/01/2019

Dates are not being calculated correctly.

I think you will have to use the @DateTimeAdd function to calculate required date values. For example, this expression returns the date of 8 days earlier than "_datestamp".

@DateTimeFormat(@DateTimeAdd(@Value(_datestamp),-P8D),%m/%d/%Y)

See here to learn more about FME built-in Date/Time functions: Date/Time Functions

Alternatively, you can also use DateTimeStamper, DateTimeCalculator, and DateTimeConverter transformers.

Hi @montanadawgz,

Just thought it might be helpful to explain why you aren't seeing the same result as in Scyphers example.

The reason your dates were staying at todays date is because you first need to format the DateTimeStamp to only include %Y%m%d.

If you do not do this, when you use the evaluate function to takeaway 8 you are doing the sum 2019030512045-8, i.e. taking 8 away from the 'seconds' so then once you format the date it always ends up being today's date. Whereas the sum you were actually wanting to do is 20190305-8.

However although this works in Scyphers example 20190228 this would not work with todays date (dates at the beginning of the month) because the evaluate function sees this value as an integer rather than a date so you would end up with 20190297 and since '97' is not a valid day the @DateTimeFormat function will fail to parse the expression.

This is why to perform calculations on dates you should look at the @DateTimeAdd function as Takashi suggested or for simplicity you could also use the DateTimeCalculator transformer.

I was able to get it functional, however with a minor change from the solutions listed here.

_date_minus8 is defined as

@DateTimeFormat(@DateTimeAdd(@Value(_datestamp),-P8D),%m/%d/%Y)

-date_minus2 is defined as

@DateTimeFormat(@DateTimeAdd(@Value(_datestamp),-P2D),%m/%d/%Y)

Notice the I added a P character before the Number and a D after the number.

They are now calculating correctly, and passing in the start date and end dates correctly.

<StartDate>@Value(_date_minus8)</StartDate>

<EndDate>@Value(_date_minus2)</EndDate>