By Steve Endow
Anyone who has written SQL queries, integrated, or otherwise had to deal with Dynamics GP data certainly has warm feelings about the colonial era use of char data type for all string fields.
This has the lovely side effect of returning string values with trailing spaces that you invariably have to deal with in your query, report, application, XML, JSON, etc.
In the world of SQL queries, you can spot a Dynamics GP consultant a mile away by their prolific use of the RTRIM function in SQL queries. .NET developers will similarly have Trim() statements thoroughly coating their data access code.
But in this bold new age of Microsoft development tools, where everything you have spent years learning and mastering is thrown out the window, those very simple solutions aren't readily available.
I am developing an ASP.NET Core web API for Dynamics GP, and being a sucker for punishment, I'm also using EF Core for data access. In one sense, EF Core is like magic--you just create some entities, point it to your database, and presto, you've got data. Zero SQL. That's great and all if you have a nice, modern, clean, well designed database that might actually use the space age varchar data type.
But when you're dealing with a relic like a Dynamics GP database, EF Core has some shortcomings. It isn't really designed to speak to a prehistoric database. Skipping past the obvious hassles, like exposing the cryptic Dynamics GP field names, one thing you'll notice is that it dutifully spits out the char field values with trailing spaces in all of their glory.
When you convert that to JSON, you get this impolite response:
Yes, they're just spaces, and it's JSON--not a report output, so it's not the end of the world. But in addition to looking like a mess, the spaces are useless, bloat the response, and may have to be trimmed by the consumer to ensure no issues on the other end.
So I just spent a few hours trying to figure out how to deal with this. Yes, SpaceX is able to land freaking rockets on a floating barge in the middle of the ocean, while I'm having to figure out how to get rid of trailing spaces. Sadly, I'm not the only one--this is a common issue for many people.
So how can we potentially deal with this?
1. Tell EF Core to trim the trailing spaces. As far as I can tell, this isn't possible as of June 2017 (v1.1.1). EF Core apparently doesn't have a mechanism to call a trim function, or any function, at the field level. It looks like even the full EF 6.1+ framework didn't support this, and you had to write your own code to handle it--and that code doesn't appear to work in EF Core as far as I can tell.
2. Tell ASP.NET Core to trim the trailing spaces, somewhere, somehow. There may be a way to do this in some JSON formatter option, but I couldn't find any clues as to how. If someone has a clever way to do this, I'm all ears, and I'll buy you a round at the next GP conference.
3. Use the Trim function in your class properties. Ugh. No. This would involve using the old school method of adding backer fields to your DTO class properties and using the Trim function on every field. This is annoying in any situation, but to even propose this with ASP.NET Core and EF Core seems like sacrilege. And if you have used scaffolding to build out your classes from an existing database, this is just crazy talk. I'm not going to add hundreds of backer fields to hundreds of string properties and add hundreds of Trim calls. Nope.
4. Use an extension method or a helper class. This is what I ended up doing. This solution may seem somewhat obvious, but in the world of ASP.NET Core and EF Core, this feels like putting wagon wheels on a Tesla. It's one step up from adding Trim in your classes, but looping through object properties and trimming every field is far from high tech. Fortunately it was relatively painless, requires very minimal code changes, and is very easy to rip out if a better method comes along.
There are many ways to implement this, but I used the code from this post:
https://stackoverflow.com/questions/7726714/trim-all-string-properties
I created a new static class called TrimString, and I added the static method to the class.
I then modified my controller to call TrimStringProperties before returning my DTO object.
And the new JSON output:
Fortunately this works, it's simple, and it's easy. I guess that's all that I can ask for.
![]()
![]()
Anyone who has written SQL queries, integrated, or otherwise had to deal with Dynamics GP data certainly has warm feelings about the colonial era use of char data type for all string fields.
This has the lovely side effect of returning string values with trailing spaces that you invariably have to deal with in your query, report, application, XML, JSON, etc.
In the world of SQL queries, you can spot a Dynamics GP consultant a mile away by their prolific use of the RTRIM function in SQL queries. .NET developers will similarly have Trim() statements thoroughly coating their data access code.
But in this bold new age of Microsoft development tools, where everything you have spent years learning and mastering is thrown out the window, those very simple solutions aren't readily available.
I am developing an ASP.NET Core web API for Dynamics GP, and being a sucker for punishment, I'm also using EF Core for data access. In one sense, EF Core is like magic--you just create some entities, point it to your database, and presto, you've got data. Zero SQL. That's great and all if you have a nice, modern, clean, well designed database that might actually use the space age varchar data type.
But when you're dealing with a relic like a Dynamics GP database, EF Core has some shortcomings. It isn't really designed to speak to a prehistoric database. Skipping past the obvious hassles, like exposing the cryptic Dynamics GP field names, one thing you'll notice is that it dutifully spits out the char field values with trailing spaces in all of their glory.
When you convert that to JSON, you get this impolite response:
"itemnmbr": "100XLG ",
"itemdesc": "Green Phone ",
"itmshnam": "Phone "
Yes, they're just spaces, and it's JSON--not a report output, so it's not the end of the world. But in addition to looking like a mess, the spaces are useless, bloat the response, and may have to be trimmed by the consumer to ensure no issues on the other end.
So I just spent a few hours trying to figure out how to deal with this. Yes, SpaceX is able to land freaking rockets on a floating barge in the middle of the ocean, while I'm having to figure out how to get rid of trailing spaces. Sadly, I'm not the only one--this is a common issue for many people.
So how can we potentially deal with this?
1. Tell EF Core to trim the trailing spaces. As far as I can tell, this isn't possible as of June 2017 (v1.1.1). EF Core apparently doesn't have a mechanism to call a trim function, or any function, at the field level. It looks like even the full EF 6.1+ framework didn't support this, and you had to write your own code to handle it--and that code doesn't appear to work in EF Core as far as I can tell.
2. Tell ASP.NET Core to trim the trailing spaces, somewhere, somehow. There may be a way to do this in some JSON formatter option, but I couldn't find any clues as to how. If someone has a clever way to do this, I'm all ears, and I'll buy you a round at the next GP conference.
3. Use the Trim function in your class properties. Ugh. No. This would involve using the old school method of adding backer fields to your DTO class properties and using the Trim function on every field. This is annoying in any situation, but to even propose this with ASP.NET Core and EF Core seems like sacrilege. And if you have used scaffolding to build out your classes from an existing database, this is just crazy talk. I'm not going to add hundreds of backer fields to hundreds of string properties and add hundreds of Trim calls. Nope.
4. Use an extension method or a helper class. This is what I ended up doing. This solution may seem somewhat obvious, but in the world of ASP.NET Core and EF Core, this feels like putting wagon wheels on a Tesla. It's one step up from adding Trim in your classes, but looping through object properties and trimming every field is far from high tech. Fortunately it was relatively painless, requires very minimal code changes, and is very easy to rip out if a better method comes along.
There are many ways to implement this, but I used the code from this post:
https://stackoverflow.com/questions/7726714/trim-all-string-properties
I created a new static class called TrimString, and I added the static method to the class.
publicstaticclassTrimStrings
{
//https://stackoverflow.com/questions/7726714/trim-all-string-properties
publicstaticTSelf TrimStringProperties<TSelf>(thisTSelf input)
{
var stringProperties = input.GetType().GetProperties()
.Where(p => p.PropertyType == typeof(string));
foreach (var stringProperty in stringProperties)
{
string currentValue = (string)stringProperty.GetValue(input, null);
if (currentValue != null)
stringProperty.SetValue(input, currentValue.Trim(), null);
}
return input;
}
}
I then modified my controller to call TrimStringProperties before returning my DTO object.
var item = _itemRepository.GetItem(Itemnmbr);
if (item == null)
{
return NotFound();
}
var itemResult = Mapper.Map<ItemDto>(item);
itemResult = TrimStrings.TrimStringProperties<ItemDto>(itemResult);
return Ok(itemResult);
And the new JSON output:
{
"itemnmbr": "100XLG",
"itemdesc": "Green Phone",
"itmshnam": "Phone",
"itemtype": 1,
"itmgedsc": "Phone",
Fortunately this works, it's simple, and it's easy. I guess that's all that I can ask for.
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles. He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.
