Email_n_Sitrep_Server

vining

Here's a workspace that consist of 2 systems, 1 system (client) is intended to be a remote system and the other system is the server which is intended to be your shops master. The idea is runs servers on your shops master and have a specific port forwarded in your shops router to your master so that client's masters can send daily sitreps or other notifications directly to your master and your master in turn can send emails if that's the action your want to take.

So one system is your shop and the other is a client. In the client there are 2 .axi's, one is pulled into the main code and there another inteded to be pulled into modules so you can pass back notifications to the main which in turn opens a connection to your shop and sends the traffic. There's a weather module in this system that is used to demonstrate this.

You can modify the script to perform daily updates or anything else you might want to do. You can have these clients check for the daily cable line up changes and if there are changes your master can respond and send these changes to the client, etc. You'll have to script this yourself but it would be easy to do.

I just pulled this code from a working file so I could send it to someone and then I figured wtf maybe someone else would like to play with it but it's not clean or sanitized so if I left any personal info in the files let me know.

The server .axi runs 5 servers but the 1st was a server I used so axis cams could send me info so this can be eliminated and made into a regular sitrep server. Only 1 should be active at a time but as a client connects another server come online to listen so hopefully 1 server will always have it's ears listening for calling clients. Of course if the client can't get through it will try again later.

If anyone has question just shoot me a pm and I'll try to explain things that aren't obvious.

John Nagy

Interesting... any reason you don't just let the remote master do the emailing? It has to have outside connectivity to reach your local master anyway...

vining

John Nagy wrote: »

Interesting... any reason you don't just let the remote master do the emailing? It has to have outside connectivity to reach your local master anyway...

It's easier to control and maintain one email account on your own master using your own account instead of multiple emails on the client's account which are subject to changes by their ISP or email service. Plus you can also update remote masters if you want, they can check in and if there is a new CATV line ups for instance you can send it back to the inquiring master. It can be 2-way if you choose. Otherwise you need to have a web server to achieve somewhat similar functionality.

ericmedley

John Nagy wrote: »

Interesting... any reason you don't just let the remote master do the emailing? It has to have outside connectivity to reach your local master anyway...

Because more and more ISPs require user and password of the account owner to access the SNMP server. It's not a ver defensible position from an indemnity standpoint if something goes wrong with the client's email account.

In addition whenever something changes on how the client access email you end up reprogramming a system and good luck billing that out...

I've been doing this for years and it works great and is easily manageable and scaleable.

DHawthorne

Back when I thought I would go nuts with the whole e-mail thing, I decided the best way was to simply give all my AMX masters an account on my own Exchange server. That way, nothing was dependent on the local ISP except the connection itself, and I had full control of the mail account, including the general idea that it was a completely unadvertised address and less likely to be a target for malware. I never took it anywhere though, mainly because I didn't wind up using e-mail notifications like I thought I would.

John Nagy

We do what Dave relates, the remote masters use our mail info, not the customer's. If they can't reach that mail server, they probably can't reach a local master to trade data with either.

vining

Anyone using this should make the following changes to the SITREP_ServMod.axs file. The way the code was written there was a timing issue for the lead server (1st one called to listen after upload). The wait in define start delayed populating the file name and creating the directory while immediately the main code called the lead server to start before this server's file name was populated. This would also cancel the wait created in define start. Then at midnight when the clients send their daily sitrep the lead server wouldn't be able to give that client a valid file name for it's attachment since it was never populated. Odd thing is most of the time it work but on occasion it wouldn't and I always figure it was a client side issue. I would get the daily email but a .dat blank file for the attachment. Of course I never looked into this problem until this morning because I received this 3 days in a row for the same client who apparently has been connecting to the same server 3 days in a row.

edit:
I also made changes to fnOpenServer() function, basically uncommented stuff that was commented out when I intially tested the code.

DEFINE_VARIABLE

VOLATILE CHAR nSServerInit = 0 ;

DEFINE_FUNCTION fnSITREP_InitServer()

     {
     if(nStats[SSERV_STAT_TYPE] == SSSERV_TYPE_SITREP) 
	  {
	  cSServerFile[SSERVER_PATH] = 'SITREP' ;
	  cSServerFile[SSERVER_FILE] = "'SERVER_',itoa(nStats[SSERV_STAT_INSTANCE]),'.log'" ;
	  fnSServFile_Create_Dir() ;
	  nSServerInit = 1 ;
	  }
     }

DEFINE_FUNCTION fnOpenServer() 

     {
     if(nStats[SSERV_STAT_STATE] == SERVER_STOPPED)
	  {
	  STACK_VAR SLONG nResult ;
	  
	  nLogIn_Step = 0 ;
	  nServerConAttempt++ ; 
	  nStats[SSERV_STAT_STATE] = SERVER_PENDING ;
	  fnServer_DeBug("'OPENING SERVER :DEBUG<',ITOA(__LINE__),'>'") ;
	  nResult = IP_SERVER_OPEN(dvServer.Port,nStats[SSERV_STAT_IP_PORT],1) ;
	       {
	       if(nResult)
		    {
		    fnServer_DeBug("'OPEN SERVER ERROR: ',fnGET_IPServer_Error(nResult),' :DEBUG<',ITOA(__LINE__),'>'") ;
		    }
	       else //Server ready and listening but no online event until a client connects!
		    {
		    CANCEL_WAIT 'SERVER_OPEN_TIMEOUT' ;
		    CANCEL_WAIT 'SERVER_ERR_DELAY_RESTART' ;
		   // CANCEL_WAIT 'SERVER_CLOSE_DELAY_RESTART' ; 
		    fnServer_DeBug("'SitrepServer Open successful, listening on port (',itoa(nStats[SSERV_STAT_IP_PORT]),') :DEBUG<',ITOA(__LINE__),'>'") ;
		    nStats[SSERV_STAT_STATE] = SERVER_LISTENING ; //does not generate an online event until a client connects ?
		    }
	       }
	  }
     
     RETURN ;
     }

DEFINE_START    //INITIALIZE 

     {
     CREATE_BUFFER dvServer,cSServerMod_Buf ;
     
     if(LENGTH_STRING(cLogin[1]) && LENGTH_STRING(cLogin[2]))
	  {
	  nRequireLogin = 1 ;
	  }
     else
	  {
	  nRequireLogin = 2 ;
	  }
	  
     if(nStats[SSERV_STAT_AUTOSTART])
	  {
	  nStats[SSERV_STAT_STATE] = SERVER_DISABLED ;  //prevent define_program from opening server during startup wait
	  }
     WAIT 1800 'SERVER_OPEN_TIMEOUT'
	  {
	  if(!nSServerInit)
	       {
	       fnSITREP_InitServer() ;
	       }
	  if(nStats[SSERV_STAT_AUTOSTART])
	       {
	       nStats[SSERV_STAT_STATE] = SERVER_STOPPED ;
	       fnOpenServer() ;
	       }
	  }
     }

DATA_EVENT[vServer]
     
     {
     ONLINE:
	  {
	  }
     OFFLINE:
	  {
	  }
     ONERROR:
	  {
	  }
     COMMAND:
	  {
	  fnServer_DeBug("'Virtual RX Cmd: (',DATA.TEXT,') :DEBUG<',ITOA(__LINE__),'>'") ;
	  SELECT
	       {
	       ACTIVE(DATA.TEXT == 'START_SERVER'):
		    {
		    if(nStats[SSERV_STAT_STATE] == SERVER_DISABLED && nStats[SSERV_STAT_AUTOSTART] && !nSServerInit)
			 {
			 nStats[SSERV_STAT_STATE] = SERVER_STOPPED ;
			 }
		    if(!nSServerInit)
			 {
			 fnSITREP_InitServer() ;
			 }
		    fnOpenServer() ;
		    }
	       ACTIVE(DATA.TEXT == 'STOP_SERVER'):
		    {
		    fnCloseServer() ;
		    }
	       ACTIVE(1):
		    {
		    fnServer_DeBug("'Unknown Command!: ',DATA.TEXT,' :DEBUG<',ITOA(__LINE__),'>'") ;
		    }
	       }
	  }
     }

Jorde_V

A good way to keep everyone update about this, would be by using a github-repo. (http://github.com)

That way everyone can hook in/fork, on your solution.