Managing Service Connect in a SOx controlled environment

Yahoo Archive
1
I was able to discuss this with an Epicor Technical Consultant and
your answer was the one he gave. I hadn't thought about two separate
installs of Service Connect until we spoke, and now it makes much
more sense to me.

Thanks to everyone who weighed in on this issue.

Jim Pratt

--- In vantage@yahoogroups.com, "Ned" <TechnoBabbly@...> wrote:
>
> You should be able to do this no problem.
>
> The best way to do this is with a completely seperate installation
of both
> Vantage and Service Connect in your sandbox/test environment.
>
> By doing this you are able to keep pretty much every setting the
same when
> you export and move the WorkFlow from one environment to the other.
This is
> also the best practice to avoid any potential cross contamination
of data
> between the databases.
>
> Since this is only needed for proof of concept and not performance,
you can
> use a lower end workstation machine instead of an actual server to
run
> these, or you can also use a virtual installation on something like
VMWare
> or MS's version of Virtual Server.
>
>
> ----- Original Message -----
> From: "jmpratt7" <james.pratt@...>
> To: <vantage@yahoogroups.com>
> Sent: Tuesday, December 16, 2008 8:07 AM
> Subject: [Vantage] Managing Service Connect in a SOx controlled
environment
>
>
> > We are new to SC and need to setup SC so we can develop workflows
in an
> > existing sandbox environment, and once proven, promote to our
> > production environment.
> >
> > Does anyone have experience with SC working in an environment like
> > this? As I have looked at the various levels of SC, it seems
that the
> > server:database that you work with are hard coded into various
elements
> > of the workflow. I am hoping to setup an arragement where we can
> > develop and then simply redirect to the production
server:database when
> > ready.
> >
> > Does anyone have any thoughts on this?
> >
> > Thanks,
> >
> > Jim Pratt
> > Ameridrives
> > Vantage since 11/26/06
> > Vantage 8.03.404B since 9/12/08
> >
> >
> > ------------------------------------
> >
> > Useful links for the Yahoo!Groups Vantage Board are: ( Note: You
must
> > have already linked your email address to a yahoo id to enable
access. )
> > (1) To access the Files Section of our Yahoo!Group for Report
Builder and
> > Crystal Reports and other 'goodies', please goto:
> > http://groups.yahoo.com/group/vantage/files/.
> > (2) To search through old msg's goto:
> > http://groups.yahoo.com/group/vantage/messages
> > (3) To view links to Vendors that provide Vantage services goto:
> > http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
> >
> >
> >
>
2
We are new to SC and need to setup SC so we can develop workflows in an
existing sandbox environment, and once proven, promote to our
production environment.

Does anyone have experience with SC working in an environment like
this? As I have looked at the various levels of SC, it seems that the
server:database that you work with are hard coded into various elements
of the workflow. I am hoping to setup an arragement where we can
develop and then simply redirect to the production server:database when
ready.

Does anyone have any thoughts on this?

Thanks,

Jim Pratt
Ameridrives
Vantage since 11/26/06
Vantage 8.03.404B since 9/12/08
3
Jim,

You need to re-import the webservices using which ever port number is
appropriate to the DB in question. You can then run your s/c routines
in test and them redirect them to live once you are happy they are
correct. Remember of course that each webservice can only point to
one place at once, so its a kind of all or nothing deal. It is the ws-
configuration utility that you need...

Does that help ?

Thanks,

Nick


--- In vantage@yahoogroups.com, "jmpratt7" <james.pratt@...> wrote:
>
> We are new to SC and need to setup SC so we can develop workflows
in an
> existing sandbox environment, and once proven, promote to our
> production environment.
>
> Does anyone have experience with SC working in an environment like
> this? As I have looked at the various levels of SC, it seems that
the
> server:database that you work with are hard coded into various
elements
> of the workflow. I am hoping to setup an arragement where we can
> develop and then simply redirect to the production server:database
when
> ready.
>
> Does anyone have any thoughts on this?
>
> Thanks,
>
> Jim Pratt
> Ameridrives
> Vantage since 11/26/06
> Vantage 8.03.404B since 9/12/08
>
4
Nick,

I am aware of the WS-Configuration utility, but as you said, it is an
all or nothing deal. I am looking for something that lets me manage
individual workflows. I'm trying to dig a little deeper.

Thanks for your response.

Jim Pratt

--- In vantage@yahoogroups.com, "nmtaylor1969" <n.taylor@...> wrote:
>
> Jim,
>
> You need to re-import the webservices using which ever port number
is
> appropriate to the DB in question. You can then run your s/c
routines
> in test and them redirect them to live once you are happy they are
> correct. Remember of course that each webservice can only point to
> one place at once, so its a kind of all or nothing deal. It is the
ws-
> configuration utility that you need...
>
> Does that help ?
>
> Thanks,
>
> Nick
>
>
> --- In vantage@yahoogroups.com, "jmpratt7" <james.pratt@> wrote:
> >
> > We are new to SC and need to setup SC so we can develop workflows
> in an
> > existing sandbox environment, and once proven, promote to our
> > production environment.
> >
> > Does anyone have experience with SC working in an environment
like
> > this? As I have looked at the various levels of SC, it seems
that
> the
> > server:database that you work with are hard coded into various
> elements
> > of the workflow. I am hoping to setup an arragement where we can
> > develop and then simply redirect to the production
server:database
> when
> > ready.
> >
> > Does anyone have any thoughts on this?
> >
> > Thanks,
> >
> > Jim Pratt
> > Ameridrives
> > Vantage since 11/26/06
> > Vantage 8.03.404B since 9/12/08
> >
>
5
Hmmm, ok Jim, here is another suggestion...

I haven't tried this, but I think it will work...

You should be able to import the same web-service under different
names both with different port numbers. You might call them
PartServiceLive and PartServiceTest for example. You could then write
workflows which call either of the webservices. The downside is that
you would have to change the websebservice names within the workflow
when you wanted to flip it to look at the other DB. Or, you re-import
one of the web-services only and change the port number...

Not sure if that made sense...!?

Nick

--- In vantage@yahoogroups.com, "jmpratt7" <james.pratt@...> wrote:
>
> Nick,
>
> I am aware of the WS-Configuration utility, but as you said, it is
an
> all or nothing deal. I am looking for something that lets me
manage
> individual workflows. I'm trying to dig a little deeper.
>
> Thanks for your response.
>
> Jim Pratt
>
> --- In vantage@yahoogroups.com, "nmtaylor1969" <n.taylor@> wrote:
> >
> > Jim,
> >
> > You need to re-import the webservices using which ever port
number
> is
> > appropriate to the DB in question. You can then run your s/c
> routines
> > in test and them redirect them to live once you are happy they
are
> > correct. Remember of course that each webservice can only point
to
> > one place at once, so its a kind of all or nothing deal. It is
the
> ws-
> > configuration utility that you need...
> >
> > Does that help ?
> >
> > Thanks,
> >
> > Nick
> >
> >
> > --- In vantage@yahoogroups.com, "jmpratt7" <james.pratt@> wrote:
> > >
> > > We are new to SC and need to setup SC so we can develop
workflows
> > in an
> > > existing sandbox environment, and once proven, promote to our
> > > production environment.
> > >
> > > Does anyone have experience with SC working in an environment
> like
> > > this? As I have looked at the various levels of SC, it seems
> that
> > the
> > > server:database that you work with are hard coded into various
> > elements
> > > of the workflow. I am hoping to setup an arragement where we
can
> > > develop and then simply redirect to the production
> server:database
> > when
> > > ready.
> > >
> > > Does anyone have any thoughts on this?
> > >
> > > Thanks,
> > >
> > > Jim Pratt
> > > Ameridrives
> > > Vantage since 11/26/06
> > > Vantage 8.03.404B since 9/12/08
> > >
> >
>
6
You should be able to do this no problem.

The best way to do this is with a completely seperate installation of both
Vantage and Service Connect in your sandbox/test environment.

By doing this you are able to keep pretty much every setting the same when
you export and move the WorkFlow from one environment to the other. This is
also the best practice to avoid any potential cross contamination of data
between the databases.

Since this is only needed for proof of concept and not performance, you can
use a lower end workstation machine instead of an actual server to run
these, or you can also use a virtual installation on something like VMWare
or MS's version of Virtual Server.


----- Original Message -----
From: "jmpratt7" <james.pratt@...>
To: <vantage@yahoogroups.com>
Sent: Tuesday, December 16, 2008 8:07 AM
Subject: [Vantage] Managing Service Connect in a SOx controlled environment


> We are new to SC and need to setup SC so we can develop workflows in an
> existing sandbox environment, and once proven, promote to our
> production environment.
>
> Does anyone have experience with SC working in an environment like
> this? As I have looked at the various levels of SC, it seems that the
> server:database that you work with are hard coded into various elements
> of the workflow. I am hoping to setup an arragement where we can
> develop and then simply redirect to the production server:database when
> ready.
>
> Does anyone have any thoughts on this?
>
> Thanks,
>
> Jim Pratt
> Ameridrives
> Vantage since 11/26/06
> Vantage 8.03.404B since 9/12/08
>
>
> ------------------------------------
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
> have already linked your email address to a yahoo id to enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder and
> Crystal Reports and other 'goodies', please goto:
> http://groups.yahoo.com/group/vantage/files/.
> (2) To search through old msg's goto:
> http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto:
> http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
>
>
>
7
The short answer is that any strategy here is going to be a
workaround. I have the same problem but just haven't decided what to do
about it as the only one invoking my web services right now is me so I
don't have to worry too much about it.



If you're lazy like me you can just edit the web.config file in the
WebService directory by hand. The port setting is at the top. You
don't need to use the configuration tool to do this.



The simplest "low-touch" approach would be to have two instances of
ServiceConnect with local webservice directories.
http://localhost/VantageServices/Part.asmx would point to your test
database on your development server, but the same URL would point to the
production database on your production server. After you've tested,
just export the workflows and import them into the new server. You
could version control the package at the same time (its just an XML
file), and even hand the file off to your sysadmin if you want to get
really elaborate about the separation of duties if your change control
procedures require this (I have an IT shop of two including myself so I
didn't include that level of segregation in my IT change control policy
as it was kind of silly).



Otherwise you're going to have to manage the process yourself.
Editing the workflow to point the WebServices calls at two different
WebService endpoints wouldn't be that difficult, but would be a manual
process and potentially error-prone. Editing the web.config file is
problematic if you have live and test workflows using the same package
of web services.



This is really kind of a challenge for ServiceConnect to deal with if
you think about it. The port/database selection is handled by the web
service configuration which lies outside of ServiceConnect's control. I
suppose one approach would be to have some sort of variable substitution
in web service reference ("test", "live", etc.) that could come from the
input file, and have that get included in the URL path that invokes the
web service. That would require you to make sure that the packages of
web service endpoints are all configured the same except for the port.
Either that or the web service itself would have to allow one to pass
the port in, which would be possible but potentially dangerous from a
security perspective (although perhaps controllable via the web.config
file, where you could list for a given package of endpoints the
permissible ports).



That's probably the best approach: have the webservices themselves
allow one to specify the port as an argument (just like Company is a
"standard" argument), and have a bit of wrapper code that determines
from the web.config file if the port is one that's allowed.



That doesn't help you now though. J



-bws



--

Brian W. Spolarich ~ Manager, Information Services ~ Advanced Photonix /
Picometrix

bspolarich@... ~ 734-864-5618 ~
www.advancedphotonix.com



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of nmtaylor1969
Sent: Tuesday, December 16, 2008 9:53 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Managing Service Connect in a SOx controlled
environment



Hmmm, ok Jim, here is another suggestion...

I haven't tried this, but I think it will work...

You should be able to import the same web-service under different
names both with different port numbers. You might call them
PartServiceLive and PartServiceTest for example. You could then write
workflows which call either of the webservices. The downside is that
you would have to change the websebservice names within the workflow
when you wanted to flip it to look at the other DB. Or, you re-import
one of the web-services only and change the port number...

Not sure if that made sense...!?

Nick

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"jmpratt7" <james.pratt@...> wrote:
>
> Nick,
>
> I am aware of the WS-Configuration utility, but as you said, it is
an
> all or nothing deal. I am looking for something that lets me
manage
> individual workflows. I'm trying to dig a little deeper.
>
> Thanks for your response.
>
> Jim Pratt
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"nmtaylor1969" <n.taylor@> wrote:
> >
> > Jim,
> >
> > You need to re-import the webservices using which ever port
number
> is
> > appropriate to the DB in question. You can then run your s/c
> routines
> > in test and them redirect them to live once you are happy they
are
> > correct. Remember of course that each webservice can only point
to
> > one place at once, so its a kind of all or nothing deal. It is
the
> ws-
> > configuration utility that you need...
> >
> > Does that help ?
> >
> > Thanks,
> >
> > Nick
> >
> >
> > --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"jmpratt7" <james.pratt@> wrote:
> > >
> > > We are new to SC and need to setup SC so we can develop
workflows
> > in an
> > > existing sandbox environment, and once proven, promote to our
> > > production environment.
> > >
> > > Does anyone have experience with SC working in an environment
> like
> > > this? As I have looked at the various levels of SC, it seems
> that
> > the
> > > server:database that you work with are hard coded into various
> > elements
> > > of the workflow. I am hoping to setup an arragement where we
can
> > > develop and then simply redirect to the production
> server:database
> > when
> > > ready.
> > >
> > > Does anyone have any thoughts on this?
> > >
> > > Thanks,
> > >
> > > Jim Pratt
> > > Ameridrives
> > > Vantage since 11/26/06
> > > Vantage 8.03.404B since 9/12/08
> > >
> >
>





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