Microsoft Dynamics AX (Archived)

Input output best practises

(0) Share

Report

Posted on by Sandri

3,850

Hello.

From OOP prespective is always talked about "the black box", something goes in, and something out.

I have been developing a webServices in AX against dozens of service providers. In testing phrase I have take the output to infolog or just use print statement.

Now I have to implement the service to production env. so the output can obviously not be an info dialog.

I can manage input data through parameters of course, but the recieving data can be everyting, I don't know it in front, I dont know how much information is retrived back, and I don't care where and how the output information is used: Report, form, another class - I just don't care.

From OOP prespective what datatype or what approach should I use?

I probably know the answer: I will store the output in container, but can someone point to a blog or more relevant information about the thinking against this situations: I don't know what will come out, but I have to store it all.

*This post is locked for comments

I have the same question (0)

All responses (5)

Answers (1)

Brandt Fundak 2,007 on at

Like (0)

Report

RE: Input output best practises

The nice thing about using a container for output is that there are already functions in the TextIO object that will allow you to stringify the container provided you pass it a delimiter. We currently use this when generating content for our bar code tags out of AX. We have a method that finds the string data and loops through continually doing += to the container until we have retrieved all of the data. We then use TextIo.writeExp() to pass the container as a comma delimited string, which our barcoding software uses to generate the tag. Personally, I think it's the best option you have for returning the output data to a file. Why reinvent the wheel?

Was this reply helpful? Yes No
Suggested answer

Joris dG 17,775 on at

Like (1)

Report

RE: Input output best practises

You can use a Struct class to represent each "record" of data. The good thing about structs in your situation is that they 1) have named (string) keys 2) they accept anytype as the values and 3) they can be serialized and unserialized (pack/unpack) to/from containers for storage in container fields in tables.

So they are a little nicer to use then containers, and if someone else will be developing different kinds of front-ends at least they can work with field names instead of indexes on a container. It also helps if the data structure changes (ordering or adding of fields or something) since that would break indexes but not "named" columns.

Was this reply helpful? Yes No
Suggested answer

Joris dG 17,775 on at

Like (0)

Report

RE: Input output best practises

Another option, depending on your scenario and how flexible this needs to be, is that you write some code that generates a table in the AOT based on the data you retrieve. I'm absolutely against having this available in production, but it would make life easy, assuming this doesn't need to happen a lot, if someone can just run a "wizard" in your dev environment that generates tables/fields (and potentially even a form) for a new service.

Was this reply helpful? Yes No
Martin Dráb 236,320 Most Valuable Professional on at

Like (0)

Report

RE: Input output best practises

Object-oriented programming won't tell you which type to use. It will help you to decompose your application to logical blocks with defined responsibilities.

Probably the most important question is what data you receive from the service. For example, if you use WCF client classes, you'll get a .NET object and the type to use for saving depends on how you serialize the in-memory object. Or if the service returns XML string, saving it as text seems to be the easiest option. By the way, note that even XML can contain encoded binary data (e.g. images or encypted data), but it's still all text (it just doesn't have to be human-readable).

Containers are useful for storing binary data, including binary-serialized objects.

Was this reply helpful? Yes No
Verified answer

Community Member on at

Like (0)

Report

RE: Input output best practises

over here you need to explain what is the output from the webservices

you said that you want to use the output whereever required... report, form another class...

but you need to explain how you want to use it Asynchronus or synchronus...

if you want to use it Asynchronus then it will be good if you store the value in a table and use it any place...

if synchronus then you can use stuct or container as output

Please verify and update us with your findings

Was this reply helpful? Yes No