ivan celeketic½©Âzw¤zØœv+ºË¢{&‰Ê貇ír‰

For any advanced customization of CRM 1.2 we need to use its API. This is a
great thing because in this way we don’t skip CRM platform and business
logic. CRM API exposes this logic and we can develop against it. So, what’s
the problem?

The thing with CRM 1.2 API is that it is stateless. Almost all classes in
the API are totally stateless. These classes do expose instance methods, but
no properties whatsoever. And many of methods are retrieving just strings
(and accepting strings as criteria). One could argue that there is no real
object model to program against. As a developer I am expecting to write
something like this:

CRMAccount account = new CRMAccount(732872);
this.txtFirstName.Text = account.FirstName;

Unfortunately it is not possible to write a code like this.

So, my basic question is: Will CRM 2005 bring us a real object model?
Something that is statefull and therefore type strongly? We need to write a
lot of “supporting� code just to manipulate all those strings – sending them
as parameters and parsing them as return values. I’m expecting that Account’s
Contact Collection be a strong type collection of Contact objects – not a
string.

I also believe that having such a robust platform as CRM is – this is not a
easy task!

--
Ivan Celeketic

jake horn

Ivan,

The problem is, CRM is built on a SOA which is by nature statless. One of
the reasons for this moving forward is that with MSCRM 2005 you should be
able to add entities to the datamodel. This create problems when building
an API that is anything but generic.

The challenge is every object model of every CRM implementation is a little
different, which creates tough problems.

I have thought that some manner for creating the "plumbing" code of working
with the API would be good. Basically an ORM for CRM. MJ Miller has been
working on some samples that might get us closer.

Jake

ivan celeketic½©Âzw¤zØœv+ºË¢{&‰Ê貇ír‰

Jake,

Thanks for quick response. This is getting interesting…

I can agree in point – make same plumbing of your own. Abstract CRM “string
concept� in your own object model and you can do some great things. Yes,
that’s the general idea! But, what happens when Microsoft changes API (let’s
say they’ll change it in CRM 2005 hopefully) – we need to do plumbing all
over again, right? This breaks the general idea of plumbing…

Adding new entities is a great thing, but what about behavior? How CRM 2005
API will expose this new entity to us?

Maybe I am getting SOA totally wrong, but for me SOA is infrastructure, not
architecture. SOA explains how to communicate, not how to implement your
business logic. If you have encapsulated business logic it shouldn’t matter
if you expose it through SOA, .NET Remoting, XML Web Services or something
else. Any thoughts on this issue are much appreciated!

By the way – anything we can see from what MJ Miller is doing? Thanks!

Ivan

arne janning

Hi Ivan!

"Ivan Celeketic" schrieb

First, Web Services aren't distributed objects and are always stateless. MJ

For more information about Web Services have a look at:
http://msdn.microsoft.com/library/en-us/dnwebsrv/html/introwsa.asp
But be warned: what Don Box describes is far away from from the current
MSCRM programming model.

MJ Miller has also worked a lot to improve the current programming model.
Peruse his posts:
http://blogs.msdn.com/mikemill/archive/2004/12/01/273254.aspx
http://blogs.msdn.com/mikemill/archive/2004/12/01/273261.aspx
http://blogs.msdn.com/mikemill/archive/2005/02/15/373344.aspx

Have a look at the code he provided in his post in this newsgroup from the
day before yesterday with the title:
"Sample web service wrapper code"

This code is not complete (and it took me a whole day to make it work on my
machines) but it will definitely give you an impression where one could go
today with MSCRM 1.x.


I think nobody really knows.

Cheers

Arne Janning

jake horn

I agree that we will have to build the plumbing code again, but I am not
sure it will be that big of a deal. We are talking about interfaces to CRUD
operations for the most part. I would suspect they will still use XML as
the message mechanism as it is easy to deal with.

I am really hoping that CRM 2005 will include APIs that are more long term.
The current APIs seem a bit forced and I don't think are the long term
solution.

I am really interested in seeing if something like Codesmith could do some
code generation for us. Everything you need to know is in the metabase, so
with some template you could built a system that builds your BO layer for
you, for each implementation. It would require being rebuilt if you add a
custom field to CRM, but that shouldn't be to difficult as all of your own
objects should inherit from the base classes and end up being
code-generation safe.

jake horn

I will throw a wrench in my previous idea by asking this question.

If code generation is a solution to the XML plumbing problem, how do you
make it portable? How do you make it adapt to each new and different CRM
implementation it is installed on?

Generate the code on install and compile again? What happens if a customer
wants to add a field. As long as your customization doesn't need to access
it, everything is OK I THINK. I am not sure.

When it all boils down everything has to be really generic.

ivan celeketic½©Âzw¤zØœv+ºË¢{&‰Ê貇ír‰

Finally manage to get MJ’s code to work.

Arne,
Thanks for pointing me to these resources.

Had to made a lot of change to code though. I’ll get back to this thread
again after ****yzing and playing with it for a while…

Jake Horn has a good point – “What happens if a customer wants to add a
field�. Any thoughts on this issue?

I was really hopping to hear that we will have something like CRMEntityBase
class that we can inherit from, but…

Ivan

mj miller \(msft\)

We've been wrestling with the whole "what happens if" problem since long
before we started coding V1. That's part of the reason that we ended up
using XML strings as parameters. It's not a great solution from a
programming and type-safety standpoint, but it does work.

Here's my take on the subject. If your customer has made a schema
modification either before of after you've built an add-on component then
there's a 0% chance that your code depends on it or else you would have
added the modification. The way the XML serializers work today is that
they'll ignore any additional attributes (unless you add an xs:any element
to the schemas, in which case the extras will end up in a language- and
framework-dependent collection of unknown elements). This is good news for
both the client and the server code.

Assume for now we have a programming environment like the sample code where
the client and server are dealing with XSD-derived type-safe classes. On the
server we'll receive an instance of a subclass of businessEntity. When the
serializer turns this into a string that the wrapper service hands to the
platform, it'll simply take the "extra" attributes which were unknown at
compile time (service compile, not platform compile - the platform is
already "safe" from extra attributes) and turn them into XML. The wrapper
will pass that string to the platform which will shred it into an internal
format, do the reqested work, and return. On the way "out" of the platform
during a Get or GetCollection, the wrapper will pass the request to the
appropriate platform Retrieve* or Query method and get back a string. The
wrapper will pass that string, and the appropriate System.Type to the
serializer, which will turn it into an object instance. The extra attributes
will end up in a collection of XmlElement that will in turn get sent to the
client.

On the client side, if your code didn't originally know about some set of
attributes then it won't need to access them in a type-safe manner. Your
client code is safe from customizations that were done outside of the
development of you custom client code. If you have extra attributes then
you'll have a class definition which includes those attributes. That class
will properly serialize because the client-side code knows all about the
extra bits - in fact, to your custom code these aren't even extras, they're
expected values.

Of course you always have the option to recompile the whole wrapper and the
client code once you've made your customizations.

--
Mj Miller
Technical Lead
Microsoft CRM

This posting is provided "AS IS" with no warranties, and confers no rights.