Re: [U2] [UV] Triggers, transaction state and interaction with the 'outside world' {Unclassified}
Mike, I think your best solution would the IBM MQSeries interface (be aware that IBM have not provided access to the transaction/rollback aspects of MQ in their UV interface, this has led us to not switch to the new UV-MQ interface). If you can't use the MQSeries interface (and fair enough this would require an MQ Series Server) I would stick with GCI. I've never compiled MSMQ into UV but I have compiled IBM MQ into UV (on AIX and Linux) and I can't imagine it will be terrible hard. I think a GCI routine called from a trigger is likely to be your best solution because: - running a phantom ... who knows if it does? do you have to wait for a response? written where? - .Net sure run another services somewhere else, another thing you need to maintain; and MSMQ guarantees delivery from the .Net software but how do you GUARANTEE delivery from UV to your .NET solution? regards, Craig --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] Triggers, transaction state and interaction with the 'outside world' {Unclassified}
Sequential file I/O is permitted while a transaction is active, so your trigger subroutine could write to a file that some server process (not in a transaction) was waiting on. Sequential file I/O statements can also work with named pipes, though these are more difficult in a Windows environment. As far as I am aware, you can also use the sockets library and/or the HTML library while a transaction is active; these suggest themselves as alternative ways to provide an interface to my postulated server process. My $0.02 worth. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Triggers, transaction state and interaction with the 'outside world' {Unclassified}
Craig
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Craig Bennett
Sent: Thursday, 8 September 2005 18:27
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] Triggers, transaction state and
interaction with the 'outside world' {Unclassified}
Mike,
I think your best solution would the IBM MQSeries interface
(be aware that IBM have not provided access to the
transaction/rollback aspects of MQ in their UV interface,
this has led us to not switch to the new UV-MQ interface).
If you can't use the MQSeries interface (and fair enough this
would require an MQ Series Server)
I'd love to try to get an MQSeries server in, but suspect such a
proposal would demonstrate all the aerodynamic properties of a lead
brick!
Pity about the absence of transaction/rollback aspects of MQ, too
I would stick with GCI.
I've never compiled MSMQ into UV but I have compiled IBM MQ
into UV (on AIX and Linux) and I can't imagine it will be
terrible hard.
I think a GCI routine called from a trigger is likely to be
your best solution because:
- running a phantom ... who knows if it does? do you have to
wait for a response? written where?
- .Net sure run another services somewhere else, another
thing you need to maintain; and MSMQ guarantees delivery from
the .Net software but how do you GUARANTEE delivery from UV
to your .NET solution?
In this particular instance, 'hard real-time' isn't an issue, a delay of
a few seconds would be quite OK.
If we can get to the stage where between the time the new employee
finishes signing their life away and the time where they sit at their
desk (gotta be a couple of minutes!) their AD account gets provisioned
so they can log in, we'll be happy as can be.
regards,
Craig
The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence Force.
If you are not the intended recipient you must not use, disclose, copy or
distribute this message or the information in it.
If you have received this message in error, please Email or telephone
the sender immediately.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] Triggers, transaction state and interaction with the 'outside world' {Unclassified}
Mike, In this particular instance, 'hard real-time' isn't an issue, a delay of a few seconds would be quite OK. I wasn't commenting on hard real-time. MQ Series and MSMQ guarantee delivery not delivery time (I could be wrong about MSMQ). Rather I was thinking about how guaranteed you need the system to be. With MQ series you can configure things like queue hardening and clustering so that guaranteed delivery means much the same as a transaction -- the message will get through or you will know straight away that it didn't (because you couldn't connect to your queue manager) (and assuming the message is actually deliverable). Advert If we can get to the stage where between the time the new employee finishes signing their life away and the time where they sit at their desk (gotta be a couple of minutes!) their AD account gets provisioned so they can log in, we'll be happy as can be. Have you thought of updating AD directly using LDAP? I have never tried creating a user account via LDAP into AD but I have done so into OpenLDAP and I have done authentication and querying into AD. I'd be happy to send you a trial package - pure basic subroutines. /Advert Of course you cannot rollback your LDAP changes (although you could undo them). If you needed your messaging solution to be able to be rolled back in MQ Series you could do an MQCOMMIT just before your COMMITED your UV transaction so I would imagine MSMQ offered something similar. Craig --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] Triggers, transaction state and interaction with the 'outside world' {Unclassified}
Mike, have a look at this MSMQ example from MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msmq/msmq_using_transactions_1gz2.asp I don't know if GCI presents any special problems under windows but this looks like it might work to send a single message transaction guaranteeing once only delivery to a transactional queue. Obviously you need to alter the sample function to actually take an input message. Craig --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Triggers, transaction state and interaction with the 'outside world' {Unclassified}
D) Have trigger spawn a phantom which instantly does the job and kills
itself???
hth,
Allen
www.tortillafc.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of HENDERSON MIKE,
MR
Sent: Wednesday, September 07, 2005 18:27
To: u2-users@listserver.u2ug.org
Cc: SOO STEATHER, MR
Subject: [U2] [UV] Triggers, transaction state and interaction with the
'outside world' {Unclassified}
Listers,
We provision our Microsoft Active Directory (and our SAP Logistics, and
..., and ...) from our UniVerse HR system [UV 10.0.x on Windows Server
2003 - we are pretty much a Windows shop]. Currently the data transfer
is done by an overnight batch process, which we have used for several
years, but we now wish to provide a more real-time solution.
The mechanism chosen by our architecture team is Microsoft BizTalk
Server, which comes with interfaces to AD and SAP already available and
tested. Our preferred method of talking to BizTalk is via Microsoft
Message Queuing Services, because this is an assured-delivery transport
[if it tells you it's got the message, it *will* arrive at the
destination]. We have a Windows '.dll' and an '.exe' command-line
utility which will talk to MSMQ from any Windows box.
In order to achieve the real-time aspect, the obvious thing to do is to
add a trigger to the relevant base file in UV, which will put a message
into MSMQ to send to BizTalk to tell everything else about the change.
To do this, we must be in Transaction State (if you weren't already, a
trigger automagically puts you into Transaction State).
This brings us to a difficulty: we can't use the command-line utility
because 'PERFORM DOS ... ' is not allowed in transaction state, nor
can we directly insert the record in a remote SQL database because BCI
CONNECT is also not allowed in Transaction State.
I think that leaves us with three theoretical possibilities:
a) Write a UV Basic program using the Sockets Interface to talk
directly to MSMQ
b) Write a C routine to talk to MSMQ via a published API (or
calling our '.dll'), and invoke this via the UniVerse GCI
or
c) Make the Trigger write a UV flag record, monitoring that file
with a Phantom which will talk to MSMQ via the DOS Shell
c is kind of a crude, 'Rube Goldberg' lash-up and less real-time, but
it would work and we could do that in a few hours programming work. But
our architecture guys would probably snigger at my 'old-fashioned'
technology.
I don't know if a or b will work in Transaction State, and we have
no institutional knowledge of either mechanism so it would be expensive
in time to try to find out.
Please can anyone offer any experienced-based advice here, or suggest an
alternative d which is easier, better, and/or quicker than my ideas.
And yes, I'd at least consider a buy my excellent product ...
response.
Thanks in advance
Mike
The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence Force.
If you are not the intended recipient you must not use, disclose, copy or
distribute this message or the information in it.
If you have received this message in error, please Email or telephone
the sender immediately.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Triggers, transaction state and interaction with the 'outside world' {Unclassified}
--- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Triggers, transaction state and interaction with the 'outside world' {Unclassified}
Mike,
I am not sure if this is officially supported but I have done it in a
couple of sites.
You can change a couple of the settings in the VOC record for the
command you want to run. DOS or create an separate entry to the
executable itself.
Change attribute 4 of the voc entry to include one of the following,
TICRGNH. I cannot remember the exact one at this stage. But one of them
Lets you execute a command during a trigger.
Cheers,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of HENDERSON MIKE,
MR
Sent: Thursday, 8 September 2005 2:46 p.m.
To: u2-users@listserver.u2ug.org
Cc: SOO STEATHER, MR
Subject: [U2] [UV] Triggers, transaction state and interaction with the
'outside world' {Unclassified}
Listers,
We provision our Microsoft Active Directory (and our SAP Logistics, and
..., and ...) from our UniVerse HR system [UV 10.0.x on Windows Server
2003 - we are pretty much a Windows shop]. Currently the data transfer
is done by an overnight batch process, which we have used for several
years, but we now wish to provide a more real-time solution.
The mechanism chosen by our architecture team is Microsoft BizTalk
Server, which comes with interfaces to AD and SAP already available and
tested. Our preferred method of talking to BizTalk is via Microsoft
Message Queuing Services, because this is an assured-delivery transport
[if it tells you it's got the message, it *will* arrive at the
destination]. We have a Windows '.dll' and an '.exe' command-line
utility which will talk to MSMQ from any Windows box.
In order to achieve the real-time aspect, the obvious thing to do is to
add a trigger to the relevant base file in UV, which will put a message
into MSMQ to send to BizTalk to tell everything else about the change.
To do this, we must be in Transaction State (if you weren't already, a
trigger automagically puts you into Transaction State).
This brings us to a difficulty: we can't use the command-line utility
because 'PERFORM DOS ... ' is not allowed in transaction state, nor
can we directly insert the record in a remote SQL database because BCI
CONNECT is also not allowed in Transaction State.
I think that leaves us with three theoretical possibilities:
a) Write a UV Basic program using the Sockets Interface to talk
directly to MSMQ
b) Write a C routine to talk to MSMQ via a published API (or
calling our '.dll'), and invoke this via the UniVerse GCI or
c) Make the Trigger write a UV flag record, monitoring that file
with a Phantom which will talk to MSMQ via the DOS Shell
c is kind of a crude, 'Rube Goldberg' lash-up and less real-time, but
it would work and we could do that in a few hours programming work. But
our architecture guys would probably snigger at my 'old-fashioned'
technology.
I don't know if a or b will work in Transaction State, and we have
no institutional knowledge of either mechanism so it would be expensive
in time to try to find out.
Please can anyone offer any experienced-based advice here, or suggest an
alternative d which is easier, better, and/or quicker than my ideas.
And yes, I'd at least consider a buy my excellent product ...
response.
Thanks in advance
Mike
The information contained in this Internet Email message is intended for
the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence
Force.
If you are not the intended recipient you must not use, disclose, copy
or distribute this message or the information in it.
If you have received this message in error, please Email or telephone
the sender immediately.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Triggers, transaction state and interaction with the 'outside world' {Unclassified}
Hi Mike A couple of suggestions. 1. Biztalk has an interface to IBM MQ message service. You could use IBM MQ to talk from U2 to Biztalk. (I do not know if there are issues with transaction state and MQ) 2. You could set up a type 1 file and write the transaction to that file. In Biztalk, you can setup a process that when something is placed in that directory (the type 1 file) it fires off a process. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
