Interesting, what platform (win/linux, etc)

What version are you running?

Definately would always recommend full commands.   I remember the day when we had to write code this way however it isn't the case anymore.

That said, it's good to be able to read code like this because it still exists out there.

This is referring to mapping between SDA and Health Insight cubes.

Please PM me so we can discuss your need further.   I am one of the Sales Engineers working with the VA.

Simply select the code to convert and then select Edit -> Advanced -

 And then either Expand or Compress  Commands.

I think full commands are much easier to read for those that might be coming into your organization and will be taking over development of your projects in the future.

It's pretty easy to convert from one to the other using the Expand and Compress commands option in Studio.

For those that might be visually impaired, it would be a lot easier to dictate expanded commands than abbreviated versions.

Just my 2 cents

If you are running IRIS for Health

From the management portal, assuming you have a Foundation namespace created you can click Health -> <select foundation namespace> -> Schema Documentation -> FHIR Annotations

If you do not have a foundation namespace created, click

Health -> Install Wizard -> Configure Foundation

Enter the name for the Namespace, click Save and then click Activate

Once you have created a Foundation namespace you should be able to access the FHIR Annotations as mentioned above.

The same holds true for Health Connect instances as well, I believe.

ODS namespaces are applicable to HealthShare Unified Care Record instances and sounds like it's not applicable to your situation.

From a business host you would use the ..SendRequestSync or ..SendRequestAsync method call.

From outside of a business host you could create a business service that took a target configname and a request message as input and use the CreateBusinessService method in End.Director to iinstanciate and call it 

Stephen

With regard to the name, it's just that, a name.  It doesn't have any effect on what the production can and cant be used for.

You can use the foundation production as a router if you want, the difference is that in that scenerio you would be adding all of the components that you needed to the production manually.   Configuring a routing production should give you the basic components needed, e.g., a service for input, a router for applying rules based routing and then an operation.   It provides the basic building blocks needed to route messages.

A generic interoperability production can route messages as well.

A foundation production is a production that is created using the Install Wizard and when created will include some useful business hosts for integrations

Stephen
An Interoperability production is a general integration production, vs a routing production is one that automatically includes some basic business hosts needed for routing messages.

Typically you would use a routing production if you wanted to route HL7 messages, for example.

An Interoperability production is a blank slate allowing you to add whatever business hosts you need.

There is no real difference in capabilities other than what is automatically created as part of the production configuration when it is first created

What does your full URL Map look like?

I would recommend getting your journal drive fixed, taking a full backup of your databases and then start journaling from there.

Whether or not you need the journals depends on how you might be using them 

Obviously they are used to recover your databases since the last backup .

They are also used for shadowing and mirroring 

What kind of error do you get when you try from a browser.

From a browser URL the method is Get.   Is your service Method a Get?

Could also be licensing.