Service Connect Questions

Yahoo Archive
1
John,

I've been playing around with ServiceConnect quite a lot recently,
and I find the lack of documentation on the web-services frustrating.
The Epicor book is very good for all the peripheral stuff ( setting
up input/output channels etc. ), but it doesn't tell you how to
connect the webservices together and what data they actually require
to make them work. Only after I have had a couple of training
sessions with our Epicor consultant have I started to understand how
the xslt conversions should be structured in order to get things to
work. Even then its not easy and involves a lot of trial and error.

I start by looking at the tracing logs particularly centering on the
update or equivalent method that is actually doing the work. I have
been advised to only turn on the tracing just before you do the
update and then turn it off again. This ensures you only capture the
really important stuff relating to the update activity itself. This
will then show all the fields that are necessary for the method to
work. This is where I got stuck initially, as its not just the
obvious ones that are required!! You may well have to supply default
values etc. for fields that you may not think a relevant ( or
obvious ), and this is where methods that create a blank dataset
intially can help.

Service connect also doesn't help you as the error messages are
ambiguous, and in some cases it will tell you that the operation has
completed ok when in reality it hasn't worked at all. :o(

My approach will vary dependant on the web service in question ( and
whether I can get it to work or not! ). Sometimes you can just hit
the update method and get away with it, and sometimes you are better
off calling the method that creates you a blank dataset and then take
it from there...

Out of interest, what is it that you are trying to do ?

Nick

--- In vantage@yahoogroups.com, "Waffqle Driggers" <waffqle@...>
wrote:
>
> Good afternoon,
>
> We are using service connect to integrate with a SQL app. We are
seeing some
> odd behavior and we can't find any documentation regarding it. I was
> wondering if anyone knows what causes this and if its normal or we
are doing
> something wrong.
>
> 1. If we want to update something (part, customer, resource, etc)
we can not
> just feed the new dataset to the update webservice. We have to use
the
> "GetRows" service to look up the existing item, merge the changes
into that
> dataset and then we can feed that to the Update webservice. If we
try to
> update without first doing a "GetRows" the process errors out.
>
> 2. If we want to add a new record we have to call the "GetNew"
sevice to get
> a blank data set, merge the data into that and feed the results
into the
> Update webservice.
>
> This seems very cumbersome to us. It seems like you should be able
to just
> feed the data into the Update service and have it update the
existing record
> or add a new one as needed. Has anyone else seen this behavior or
have some
> any insight?
>
> Thanks,
> John Driggers
> Zabatt Inc
>
>
> [Non-text portions of this message have been removed]
>
2
Good afternoon,

We are using service connect to integrate with a SQL app. We are seeing some
odd behavior and we can't find any documentation regarding it. I was
wondering if anyone knows what causes this and if its normal or we are doing
something wrong.

1. If we want to update something (part, customer, resource, etc) we can not
just feed the new dataset to the update webservice. We have to use the
"GetRows" service to look up the existing item, merge the changes into that
dataset and then we can feed that to the Update webservice. If we try to
update without first doing a "GetRows" the process errors out.

2. If we want to add a new record we have to call the "GetNew" sevice to get
a blank data set, merge the data into that and feed the results into the
Update webservice.

This seems very cumbersome to us. It seems like you should be able to just
feed the data into the Update service and have it update the existing record
or add a new one as needed. Has anyone else seen this behavior or have some
any insight?

Thanks,
John Driggers
Zabatt Inc


[Non-text portions of this message have been removed]
3
Hi john,

You can use GetByID instead of GetRows for the first
case.



When you are interfacing with vantage you should be following the
business logic the UI calls [use tracing].



GetNew defaults and initializes items in the dataset to be later passed
to the update method.

GetByID first lets you check the sanity of your update you propose and
finds the record to pass to the update method.



If you simply pass things to the update method, you risk some corruption
to the database.

You could have anomalies between performing the same action within the
vantage client and your workflow.



Hope this helps.



Stephen



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Waffqle Driggers
Sent: 19 July 2008 16:16
To: vantage@yahoogroups.com
Subject: [Vantage] Service Connect Questions



Good afternoon,

We are using service connect to integrate with a SQL app. We are seeing
some
odd behavior and we can't find any documentation regarding it. I was
wondering if anyone knows what causes this and if its normal or we are
doing
something wrong.

1. If we want to update something (part, customer, resource, etc) we can
not
just feed the new dataset to the update webservice. We have to use the
"GetRows" service to look up the existing item, merge the changes into
that
dataset and then we can feed that to the Update webservice. If we try to
update without first doing a "GetRows" the process errors out.

2. If we want to add a new record we have to call the "GetNew" sevice to
get
a blank data set, merge the data into that and feed the results into the
Update webservice.

This seems very cumbersome to us. It seems like you should be able to
just
feed the data into the Update service and have it update the existing
record
or add a new one as needed. Has anyone else seen this behavior or have
some
any insight?

Thanks,
John Driggers
Zabatt Inc





[Non-text portions of this message have been removed]